Unshackle Spin from Clap 3

[rylev]

We've had two failed attempts at updating our dependency on Clap from version 3 to version 4:

• https://github.com/fermyon/spin/pull/2851
• https://github.com/fermyon/spin/pull/1198

The issue is a breaking change from clap 3 to 4 which does not have a known work around. Clap 4 doesn't lazily evaluate args like Clap 3 did, and once it discovers an arg that can only go into the trigger_args bucket of otherwise unknown args, it starts slurping up everything else and putting it into trigger_args.

This means the following used to work but no longer does:

spin up --some-arg-meant-for-the-trigger --env "foo=bar"

This does not work because as soon as --some-arg-meant-for-the-trigger is seen, everything gets lumped into trigger_args. If --env is put first, than things work as expected.

[itowlson]

More related links:

• Another attempt: https://github.com/fermyon/spin/pull/1198
• The contributor who sent the above PR proposed this (make the distinction explicit instead of relying on order): https://github.com/fermyon/spin/issues/1214
• The Clap 4 issue for this: https://github.com/clap-rs/clap/issues/1404

[lann]

I was having a think about this and wondered to myself "how did this ever work in Clap 3?" Well reader, it doesn't:

$ spin up --listen --direct-mounts localhost:9876
...
Serving http://127.0.0.1:9876

[lann]

Some options:

• Implement our own "argument pre-processor" that takes all args after up and extracts all known flags (and their values!) before passing on to the clap subcommand parser. This would be annoying and possibly difficult, but could probably approximately preserve the existing behavior.
• Require that trigger args come after up args. I don't think we necessarily need to require the -- separator here, but we still might want a validator that looks for known up args in the trigger args list in order to give users a more useful error than the "unknown arg" that the trigger args parser would give.