Introduce config version v3, allow proxy_addresses to be given in the config

[ryanclark]

This introduces a new version of the config, v3, as we're adding a new item to the schema - proxy_addresses.

This allows us to go straight to direct dialling the proxy server if specified via proxy_addresses, as we know it's not an auth server and we don't need to attempt to direct dial it.

This keeps backwards compatibility with v2, where if a proxy server is specified in auth_addresses it'll still connect. It will put a warning in the console telling the user to upgrade their config version and specify proxy_addresses instead, like so:

(Do we want to add an item to a documentation page about this change? I've left the URL as an example of what we can display to the user)

For the tests, I've duplicated a few v2 tests and changed the version to v3 - just sanity checking nothing strange happens when we upgrade the config version.

This also updates the CLI reference docs to set the version to v3, and specify proxy_addresses. I'm not sure if there's more documentation I need to update, but I'll take a look through.

I took the chance to refactor the config validation code, splitting it into its own file instead of adding more code to the already long service.go.

This would close #11524, as we'll not need dial_mode as we know whether the specified URI is a proxy server or auth server.

[zmb3]

nit: for all these checks, instead of a == or !=, I would find a switch easier to reason about.

switch fs.Version {
case defaults.TeleportConfigVersionV1:
    // v1 logic
case defaults.TeleportConfigVersionV2, defaults.TeleportConfigVersionV3:
    // v2/v3 logic
}

[ryanclark]

I had chose to do it this way so we have less places to update every time we do a new config version, happy to change it to a switch statement though

[zmb3]

If you can determine that the config version is v3, you can skip dialing via tunnel here. V3 configs will be opt-in, so we can make proxy_servers required for tunneling.

[ryanclark]

Ah that TODO is an old comment that can be removed. This tunnelling is needed as it's the fallback after trying to direct dial the value from AuthServers.

I've made it so v3 configs are default - is there a reason we'd make it opt-in? The way I saw it was there's no backwards compatibility issues, so we can skip straight to v3 being the default.

[ryanclark]

We don't know the config version in this function to know to make v3 only direct dial an auth server or tunnel a proxy server. We can guess, which is what I'm doing now - if proxy addresses are specified, tunnel to them, if not, direct dial to the auth server value and fall back to tunnelling if it doesn't work.

Maybe it would be nicer to pass the configuration version to here, so we can restrict the fallback of tunnelling the auth addresses value to v2 and below.

[zmb3]

Don't use the auth connect addr in the help message, as the presence of auth port 3025 will confuse users (prefer 3080 or 443).

[ryanclark]

I missed this and have set it to [none] like the others. Shall I add an example URL there on port 3080 or 443, or leave it as [none]?

[rosstimothy]

I realize this is still a draft, but I stumbled across this and while everything here looks good I have a question:

Should proxy_addresses actually be proxy_address?

Perhaps a follow up PR to this now that there is a config v3 would be to add auth_server and deprecate auth_servers?

@zmb3 thoughts?

[nklaassen]

Came across this because I am interested in https://github.com/gravitational/teleport-private/issues/135

If it is possible to do this in a backward-compatible way without bumping the config version to v3, I think we should do that.

As Tim mentioned, I think we should also take this opportunity to de-pluralize the fields, because we don't actually support more than 1 auth/proxy address.

We could add a proxy_server field, which if used, will only try to connect to a proxy without fallback. Similarly, we could add a auth_server field (not auth_servers), which if used will only try to direct dial to auth, without fallback. The feature would remain opt-in because you would need to explicitly use these new fields. Over time we could deprecate the current auth_servers field.

I don't see a need to bump the config version to v3. New resource versions can be confusing to users, and if it's not absolutely necessary I think we should avoid it.

[zmb3]

That makes sense to me, thanks for the suggestion @nklaassen. We decided on config v3 before we talked about making auth_server singular.

I'll get confirmation in next product sync.

[ryanclark]

Closing as I restarted this work in #15761