fix(autoconfig): process each environment on its own queue

[aaron-zeisler]

Summary

LaunchDarkly sends the Relay Proxy its configuration on one stream. One goroutine reads that stream. Before this change, the goroutine completed all work for a message before it read the next message.

Some of that work is slow. When an environment gets a new SDK key, the Relay Proxy must build a new SDK client and wait for that client to connect. The wait can last as long as Main.InitTimeout. The default value is 10 seconds.

The goroutine did not read the stream during that wait. Therefore one environment delayed every other environment. Credential revocations for other environments also waited.

This change gives each environment its own queue and its own worker. The stream goroutine adds each message to the correct queue, then continues.

With 29 environments that rotate keys together, the worst case improves from approximately 4.8 minutes to approximately 10 seconds. Each environment now waits only for its own build.

Jira: SDK-2921

Why this was a regression

Relay v8 builds the client asynchronously. The concurrent-keys work made the build synchronous to get safe rollback: the Relay Proxy moves the connection only after the new client connects. That behavior is correct, and this change keeps it. The problem is the shared goroutine, not the synchronous build.

Two points about the scope:

• This affects every account that uses auto-configuration, not only accounts that use concurrent keys. A payload without the sdkKeys array still produces an anchor change, because EnvironmentRep.ToParams builds the accepted-key set from the single sdkKey field when the array is absent (see the "Old-format payload" branch in internal/envfactory/env_rep.go).
• Startup is not affected. At construction the anchor is already the configured SDK key, and the Relay Proxy starts that build asynchronously. Only a key rotation reaches the slow path.

The change

AutoConfigActionQueue wraps the existing projmanager.AutoConfigActions interface. relay/relay.go creates it.

Three properties make this seam safe:

1. ProjectRouter and EnvironmentManager never read state back from the handler. Every call to it returns nothing. Their maps stay on the stream goroutine and need no lock.
2. Message order and version bookkeeping stay on the stream goroutine. StreamManager still processes one message at a time.
3. Relay-wide state already has locks. addEnvironment takes Relay.lock, and EnvironmentLookup has its own mutex.

Concurrent work across environments is also not new. Each environment already runs a credential cleanup ticker in its own goroutine, and that ticker changes the same relay-wide state. This change extends a pattern that the design already accepts.

Please review these decisions

• The queue key includes the filter key. A filtered environment is a separate context with its own SDK client and its own anchor. It must not wait behind the default environment that shares its environment ID.
• ReceivedAllEnvironments is now a drain barrier. It sets the fullyConfigured flag, which controls whether Relay serves requests and what the status endpoint reports. It must not fire while the Relay Proxy still applies environments from the same payload. This makes readiness stricter than before. The flag previously became true as soon as Relay read the payload.
• The barrier waits on its own goroutine. A barrier that blocked the caller would restore the original problem for put payloads.
• A semaphore limits concurrent actions to 32. A put that adds every environment would otherwise construct them all at the same time. Before this change, the stream goroutine built them one at a time.
• A worker exists only while its queue holds work. The worker retires the queue under the same lock that submit uses for lookup. Therefore no action can reach a retired queue, and two workers cannot run for one environment.
• execute recovers from a panic. A panic that escaped would kill the worker and leave the queue in the map. That environment would then stop all configuration updates for the life of the process.
• Close waits 2 seconds, then abandons the remaining work. An indefinite wait would hold the process open during a slow build. Abandonment is safe: addEnvironment refuses new work after Relay closes, EnvContext.Close is idempotent, and the re-anchor rechecks the closed flag after its build.