Machine ID: Refactor tbot CLI

[timothyb89]

This significantly refactors the tbot CLI. In addition to a major overhaul of our CLI config handling, it also exposes a number of new subcommands for starting more than just an identity output via pure CLI.

New command examples

# old commands are now under the (default) `tbot start legacy`, so the `tctl bots add` example still works
tbot start --destination-dir=./tbot-user \                                                                                                                                                                    
  --token=<snip> \
  --proxy-server=example.com:443 \
  --join-method=token --data-dir=./tbot-data

# start in identity mode (roughly equivalent to legacy, but with new-style flags)
$ tbot start identity --destination=./tbot-user --storage=./tbot-data --proxy-server=example.com:443 --join-method=token

# most commands have common aliases to improve memorability
$ tbot start ssh --destination=./tbot-user --storage=./tbot-data --proxy-server=example.com:443 --join-method=token

# start in Kubernetes mode
$ tbot start kubernetes --destination ./tbot-user --storage=./tbot-data --proxy-server=example.com:443 --join-method=token --kubernetes-cluster kind-demo

# start a database tunnel
$ tbot start db-tunnel --listen tcp://0.0.0.0:1234 --storage=./tbot-data --proxy-server=example.com:443 --join-method=token --service postgres-demo --username demo --database demo

# start the SPIFFE SVID output
$ tbot start spiffe-x509-svid  --destination=./tbot-user --storage=./tbot-data --proxy-server=example.com:443 --join-method=token --svid-path /foo

These commands and flags all now have 1:1 parity with tbot configure. That means you can easily convert any of these example commands to a config file by replacing tbot start with tbot configure:

# try running a bot manually to test flags
$ tbot start spiffe-x509-svid --destination ./tbot-user --storage=./tbot-data --proxy-server=example.com:443 --join-method=token --svid-path=/foo

# once satisfied, easily convert to a config file
$ tbot configure spiffe-x509-svid --destination ./tbot-user --storage=./tbot-data --proxy-server=example.com:443 --join-method=token --svid-path=/foo > tbot.yaml

# start from the config file
$ tbot start -c tbot.yaml

The --destination and --storage flags now also universally accept URIs, so memory:// and kubernetes-secret:// should work as expected.

Goals

Some (re-)design goals per #44509 include:

1. Exposing various tbot output types and services through pure CLI
2. Cleanly cutting over to new terminology for all new subcommands (--storage instead of --data-dir, --destination that accepts URIs instead of --destination-dir, etc)
3. Maintaining support for legacy syntax

While iterating, I also prioritized:

1. Sharing as much code as possible between each subcommand, as well as the tbot start and tbot configure variants of each. An earlier iteration unrolled all of this, and bugs very rapidly resulted from drift between copy and pasted code blocks, not to mention the spectacular line of code count.
2. Moving away from the effectively global namespace of the CLIConf struct. This struct has become unmanageable and led to conflicting usages and definitions of fields. Every command should make its flag requirements and fields explicit (aside from the few true globals)
3. Ensuring our kingpin configuration did not enforce any new and unergonomic flag ordering constraints. kingpin flags don't have nice inheritance rules so defining common arguments on the tbot start level led to:
   • ugly positioning requirements: tbot start --proxy-server foo.com identity --destination ./bar
   • inability to properly exclude old/renamed arguments from new commands

To attempt to solve everything at once (very dangerous 😬) I've attempted to adapt tctl's TryRun() to allow for reusable commands that we can execute as either start or configure subcommands. Defining new "modern" style subcommands is quite lightweight as the shared set of parameters can be embedded easily, and the "start" and "configure" actions can be passed in at init time.

changelog: Introduced use-case specific commands to tbot to provide a better out-of-box experience.

[timothyb89]

I think I'm ready to open this for review. I still want to spend tomorrow adding unit tests to verify each command's individual flag handling, but also want to start collecting feedback before I'm OoO this week.

[strideynet]

So nice seeing the hundreds of flags pulled out of here.

[strideynet]

This is looking really good with a separate package for the CLI concerns. This has definitely come together nicely.

I think at a later date, I'd be slightly curious about moving the actual handler code down into cli or tying it more to the command constructors themselves. But I think that's definitely out of scope for this PR and would realistically bring only minor improvements.

Approving this on the basis of some more tests :')

[strideynet]

Let's make the changelog message a little more user facing as well. Perhaps:

changelog: Introduced use-case specific commands to tbot to provide a better out-of-box experience.

[public-teleport-github-review-bot]

@timothyb89 - this PR will require admin approval to merge due to its size. Consider breaking it up into a series smaller changes.

[rosstimothy]

This looks like a more polished version of what tctl uses. Do you see any benefit/problems with moving this into a more common cli package that all of our tools could one day use?

The only tbot specific things I've seen so far is the ConfigMutator, but that could very well be made generic:

type ConfigMutator[Config any] interface {
	ApplyConfig(config Config, l *slog.Logger) error
}

[strideynet]

TimB's on leave until next week - I figure that since this PR is already pretty large - the overall idea of extracting this to something reusable makes sense but we perhaps ought to do that in another PR. I think there's a few finishing touches/refinements we'll want to add if other folks are going to use this.

[rosstimothy]

I wasn't so much asking for something in this PR to change, just curious if you all thought it would be a good idea in general.