maintenance window agent export logic

[fspmarshall]

Implementation of the agent-side logic corresponding to #22850

This PR introduces maintenance window export logic for the kube controller and systemd unit based external upgraders. When enabled, the teleport agent periodically loads maintenance window info from auth and exports it to an appropriate location for the upgrader to consume it.

The behavior is toggled by setting an environment variable (TELEPORT_EXT_UPGRADER=kube|unit). This flag is not intended to be set by users. Upgrader packages will set the appropriate value automatically.

Note: this PR is currently pointing toward fspmarshall/maintenance-window-auth-v2 and will be rebased to master once the changes it depends on get merged.

[mdwn]

These are largely nits. Feel free to push back on whatever!

[mdwn]

I was pinged on a review recently and advised not to store context in structs. Seems like a reasonable idea. It'd be easy enough to adjust the call to Run in service.go to just say something like:

		process.RegisterCriticalFunc("maintenancewindow.export", func() error {
                    return exporter.Run(process.ExitContext())
                )

I don't know that Close would be necessary if you did this, as the context would be canceled as part of process shutdown.

[fspmarshall]

I am going to push back on this one... storing a request scoped (or potentially request-scoped) context in a struct is bad, because it makes it too easy to accidentally introduce weird memory leaks. This is because request-scoped context frequently hold onto references to lots of request-scoped date (e.g. certs).

Using context.Background() to create a cancellation helper for a component that does cancellable I/O is fine IMO. Rather than bake our own alternative closure mechanism, if I were to deviate from this pattern I'd probably deviate by creating a custom CloseContext helper type that implements context.Context and never contains any context values (i.e. a context type that statically promises that it does not hold references to request-scoped values).

We could use process.ExitContext(), but IMO that's not a great pattern. I've found myself leaning toward the opinion that persistent components should be explicitly rather than implicitly closed where possible. Mostly because this allows control of the order of closure. Context cancellation cancels all layers simultaneously, which has caused confusing errors for us in the past. Mostly a moot point here, since no other components rely on exporter being healthy, but it's a pattern I'm trying to force myself to stick to.

[mdwn]

I like this a lot!

[public-teleport-github-review-bot]

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

[github-advanced-security]

You have successfully added a new Trivy configuration .github/workflows/trivy.yaml:trivy. As part of the setup process, we have scanned this repository and found no existing alerts. In the future, you will see all code scanning alerts on the repository Security tab.