Migrate urfave/cli to v3 + add manpage subcommand

[folliehiyuki]

The main motivation of this PR is better support for shell completion. We won't need to maintain custom completion scripts, while having additional support for fish shell and powershell.

References:

• https://cli.urfave.org/migrate-v1-to-v2/
• https://cli.urfave.org/migrate-v2-to-v3/

[folliehiyuki]

I noticed that urfave/cli v3 removed a hidden builtin feature to generate CLI documentation and put it into a separated Go package. Even though this is a bit out of scope for this PR, I added another commit to include a subcommand to generate man page for sops.

[felixfontein]

The last time I did investigated github.com/urfave/cli/v3 it was processing arguments sufficiently different that this would be a breaking change for the CLI interface of SOPS, since it parses some things quite differently, and thus not acceptable. Is there now some compatibility mode with v1? Or is this PR a breaking change?

[folliehiyuki]

The last time I did investigated github.com/urfave/cli/v3 it was processing arguments sufficiently different

Can you explain the behavior? Here is some differences I spotted:

• flags must be specified before arguments
• there is no longer a concept of global flags. Flags can be passed through to subcommands by default

Apart from those, I don't see anything strange (yet). I only use a small subset of sops' functionalities, so I haven't tested every subcommand. Whether the above changes are breaking or not is up to you. Personally it doesn't affect my daily usage.

[folliehiyuki]

There are also differences in how --help flag and help subcommand are used (help subcommand can be invoked by another subcommand by default), as well as how the help text is displayed for root command and subcommands. If you desire the old help behavior, there are workarounds.

[folliehiyuki]

Even with Local = true set for all global flags, they still don't behave the same as the current sops command (global flags can still be specified anywhere in the command line).

I opened urfave/cli#2208 as I don't know whether this is an intended behavior.

[folliehiyuki]

I was tempted to inject Local = true into all global flags after they are defined, but the approach seems to be messy, and we probably will need to wrap the slice elements with a custom interface. Every global flag is defined plainly here, even with a level of duplication, for simplicity.

Ref: urfave/cli#2073

[folliehiyuki]

I rebased onto main branch to resolve the merge conflict. urfave/cli package was also bumped from 3.4.1 to 3.6.0 in the process, since the latest version fixed the issue with local flags I mentioned above.

[folliehiyuki]

Hi @felixfontein ! Is there anything I should work on in this PR? It's ready for another review. Rebasing it onto master branch is pretty hard if it gets staled for too long.

[felixfontein]

Sorry, but I'm not sure whether I'll have time anytime soon to look at this in more detail.