Make the proxy read from autoupdate_agent_rollout

[hugoShaka]

As described in #47126, This PR makes the proxy service read the autoupdate_agent_rollout resource and modulate the update response based on the resource content and the updater group.

Sorry for the PR size, but 3/4 of the locs are tests 😅

Basically, autoupdate_agent_rollout looks like:

kind: autoupdate_agent_rollout
spec:
  start_version: v1
  target_version: v2
  schedule: regular
  strategy: halt-on-failure
  mode: enabled
status:
  groups:
    - name: dev
      start_time: 2020-12-09T16:09:53+00:00
      state: active
    - name: staging
      start_time: 0000-00-00
      state: unstarted

Depending on the requested group state, the proxy will tell the agent to update or not. In this example, "dev" agents should update now to v2 while "staging" agents should not update and their desired version is still v1.

In addition to the RFD original design I aligned the configuration and answers between the new RFD184 updates, and the existing RFD109 updates APIs. Now:

• RFD 109 channels honour the content of autoupdate_agent_rollout if it's here
• In the absence of autoupdate_agent_rollout, the RFD 184 API will also fallback to RFD 109 channels to ensure maximal compatibility and a seamless transition between both systems.

Those changes ensure that both RFD109 and RFD184 APIs answer the same thing and update agents at the same time. The goal is to make the transition seamless for users, so they don't have to deal with 2 separate configurations, update schedules, and sets of agents.

Note

Existing systemd-based updaters and old kube-agent-updaters will still rely on the agent-exported maintenance windows. Those might cause updates to happen outside of the RFD184 rollout plan (although the target version will be correct). We could try to predict when maintenance will happen and change the way auth exports windows to the agent. However this would b accurate only for time-based rollouts as we cannot predict if a group will get updated with the "halt-on-failure" strategy.

This PR also contains the following minor changes:

• makes the /find endpoint cache per-group (we obviously won't be able continue this when we'll add per UUID reponse, but I think it is still desirable to do the least work possible in the find endpoint).
• reuse the same constant for the group parameter name

Goal (internal): https://github.com/gravitational/cloud/issues/10289

Depends on: #49484 (renaming AU-related content in lib/web)
Depends on: #49101 (running the autoupdate_agent_rollout controller in auth)

[creack]

Looks good to me. Comments only on nitpick styling. Keep in mind I am very new here, I may not be familiar with existing patterns / style.

[sclevine]

Add godoc on exported identifier?

[r0mant]

Bot.