add new CLI command to simplify shell completion

[alexrashed]

This PR adds a new shell command to support the configuration of auto-completion for the LocalStack CLI.
It uses the Click-feature for Shell completion: https://click.palletsprojects.com/en/8.1.x/shell-completion/

Unfortunately, the configuration is a bit cumbersome:

In order for completion to be used, the user needs to register a special function with their shell. The script is different for every shell, and Click will output it when called with _{PROG_NAME}_COMPLETE set to {shell}_source. {PROG_NAME} is the executable name in uppercase with dashes replaced by underscores. The built-in shells are bash, zsh, and fish.

This is where the new completion command comes in. It basically just simplifies printing the shell completion code for a given shell. This completion code can then - depending on the shell - be used to configure the shell completion.
By implementing a specific command, it's also easy to ship an extensive documentation explaining the feature (as you can see in the code).

When starting to work on this, I used click-contrib/click-completion for a first PoC. It would even have an install command and powershell support, but I decided against it because:

• It would have added Jinja2 as an install dependency.
• It is not too well maintained, there hasn't been a proper release for quite some time (Click >= 8 is not supported in the latest release on PyPi).
• It seem like the powershell support might be broken right now, and click allows to easily add new completions.

[thrau]

this looks like a really nice quality of life improvement! i wonder whether we should maybe group certain commands into utility categories, such as localstack cfg localstack cfg-cli localstack cli or something of sorts, to keep the list of top-level commands short and make sure they focus on the core functionality.
WDYT? /cc @SimonWallner

[alexrashed]

That's a good point... There is already the config command, but that seems semantically closer to the actual configuration of the runtime / providing tools to handle the runtime config.
But I think it might also be good to have it on the top level because:

• It seems to be quite common:
  • kubectl completion fish (same for helm)
  • docker completion fish
    • That's an interesting one, it doesn't list the command in the help but it works.
  • ng completion
  • It's the sample for click-contrib/click-completion
• I don't really see other commands exposed for the CLI per-se. I think other commands, which are somewhat related to the CLI like login will still stay on the top level?

Do you think there are going to be other commands which would semantically belong to this command?
Maybe we should also hide it in the list of commands like the docker cli does?

[github-actions]

LocalStack Community integration with Pro

2 082 tests   1 799 ✔️  1h 21m 14s ⏱️
       2 suites     283 💤
       2 files           0 ❌

Results for commit af6e2a6.

♻️ This comment has been updated with latest results.

[coveralls]

coverage: 82.729% (+0.05%) from 82.68% when pulling af6e2a6 on add-cli-complete-command into 71178ff on master.

[alexrashed]

FYI: The failing Community Integration Tests against Pro are addressed in #8426. But these tests should not be affected by the changes in this PR.

[thrau]

nice! since it seems industry practice, let's do it 👍