Add new Gemspec/RequireMFA cop

[dvandersluis]

Following #10239, adds a new Gemspec cop to ensure that the rubygems_mfa_required metadata is set.

By default operates in Strict mode which requires rubygems_mfa_required to be set to true. If given Strict: false, it just checks that it is given a value.

---

Before submitting the PR make sure the following are checked:

• The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• Wrote good commit messages.
• Commit message starts with [Fix #issue-number] (if the related issue exists).
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

[bbatsov]

Looks good to me. I'm just wondering about the name Strict, as I might not have guessed what it does without reading your PR description.

[dvandersluis]

Happy to change it if you have any ideas!

[koic]

The Strict option looks unnecessary. I think it's better to make sure that MFA is always enabled because it's about security.
If there is any reason why MFA cannot be enabled, the user has the option of disabling cop instead of Strict: false. This will simplify the use and design of cop.

I've heard talks by RubyGems developer about enabling MFA at past conferences. I think it's good to be able to detect this :-)

[bbatsov]

That would be fine by me as it solves the problem with the name. :D

[dvandersluis]

@bbatsov @koic I absolutely agree, my rationale for creating this was that we can encourage every gem that uses RuboCop to require MFA for pushes, which is best for the community.

I've updated the PR to not have the Strict config anymore. I originally added it because the RubyGems docs state that you can set the value to 'false', but disabling the cop in that case is fine too.

[koic]

Thank you for the update! This looks good to me. Can you squash your commits into one? As noted in Martin Fowler's "Refactoring 2nd edition", refactoring is closely tied to addition of new feature. Therefore once commits are separated, the context in which the refactoring took place is unknown.

[dvandersluis]

Sure, I squashed the autocorrection commit in. I think the refactoring commit makes sense on its own because it's affecting multiple cops. I'm partial to @marcandre's blog about it 😁

[koic]

As a most active contributor for several years, I like the pragmatic policies of Martin Fowler (No one can talk about refactoring better than he). Anyway that's it for this topic, as it's not the main subject of this PR and I'm grateful for your contribution :-)