Add DSS pool load balancer component

[BenjaminPelletier]

Is your feature request related to a problem? Please describe.
ASTM standards envision interchangeable DSS instances hosted by separate USSs improving resiliency of the overall ecosystem by being able to fail over to another USS's DSS instance when a primary DSS instance fails[1][2]. However, currently, the InterUSS DSS implementation does not provide this capability to USS users; the USS users must provide it on their own.

[1] "USSs can interact with any DSS instance within a pool and switch over to any other instance in the event of a failure." ASTM F3548-21 3.2.18
[2] "Mitigation—The affected USS switches to another DSS instance in the pool." ASTM F3548-21 X5.2.4

Describe the solution you'd like
InterUSS should optionally provide a "pool load balancer" that exposes the application APIs of a DSS instance. It will usually direct traffic inward to the existing DSS instance load balancer, but when certain types of failures are detected, it will instead direct traffic to the application API of one of the other specified DSS instances. Visually, this feature would add the green boxes:

Describe alternatives you've considered
It is unclear whether this feature should be an enableable part of the existing DSS instance deployment, or whether it should be a stand-alone deployment. Simplicity would seem to recommend being a component the existing DSS deployment, but this would make the pool load balancer more likely to fail along with the DSS instance, thus negating some of the benefit of failover.

Additional information
An important design choice will be determining the conditions under which this new DSS pool load balancer would start and stop sending traffic away from its primary DSS instance. Using existing health monitoring information from the DSS instance deployment would likely be a good first pass, though there may be some work to make that information accessible outside the Kubernetes cluster if this DSS pool load balancer is to be deployed separately from a DSS instance.

[BenjaminPelletier]

As suggested by @callumdmay, an additional capability this feature could add is to send a small, configurable amount of traffic (e.g., one request per hour) to other DSS instances even when all instances are working properly in order to expose a failure in another USS's pooled instance to the planning USS (if one existed). The absence of observing such failures could provide the planning USS with confidence that the pool was still configured and working properly without any additional/separate probing infrastructure or load.

Additionally, one contribution to determination of when to send traffic to alternate DSS instances could potentially be the enhanced/pool health check endpoint (or its underlying functionality) discussed in #1171.