Show GPG error before entering commit editor when rewording non-latest commits

[m04f]

• PR Description

When GPG signing is enabled but overrideGpg is false, attempting to reword a non-latest commit would show the "Feature not vailable for users using GPG" error only after the user had already entered the commit message.

Now the error is displayed immediately when attempting to start the reword operation, before opening the editor.

Closes #4611

• Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

Thanks for contributing, the fix looks good, just one small nitpick below.

One more thought: the original if statement is still there now, but will never be true any more. I'm undecided what we should do with this:

1. keep it there, in case we refactor the code again in the future and forget to check upfront, maybe from a different call site
2. replace it with a panic (which would be the equivalent of assert in other languages)
3. remove it altogether

Any thoughts? If we do 1., I suppose we should at least add a comment there.

[m04f]

I had the same thought about the original if statement when writing this. I think keeping it there could be useful in case it becomes reachable again through another call site in the future.

[stefanhaller]

I think keeping it there could be useful in case it becomes reachable again through another call site in the future.

Works for me, but as I said I think we should add a comment to that effect, so that future readers of the code aren't confused. Something like

	// This will never be true because controllers are supposed to check for it
	// before calling this method. Keeping it here in case we add new call sites
	// in the future that don't do the check.

[stefanhaller]

Thanks, looks great now.

Two more things to keep in mind for future PRs:

• please don't just pile up new commits; try to create a sane commit history. Don't assume that all commits will be squashed anyway when merging, we don't do this here. (In this case, just squash the three commits; in the future, a good way to handle this is fixup commits.)
• please don't create pull requests from your fork's master branch; create a feature branch instead. This makes it less awkward for maintainers to push fixups if necessary, or to rebase your branch.