Minimize discovery requests from broadcaster

[yondonfu]

Bs currently can send a lot of discovery requests to Os when using the default on-chain discovery mechanism on mainnet. Many of these discovery requests are cancelled in-flight because once B receives a sufficient # of responses or hits a timeout, the remaining in-flight requests are cancelled. We believe that many cancelled in-flight requests can cause:

• Os to see TLS handshake errors in their logs because the connection was abruptly aborted before the TLS handshake completed
• In certain cases, this type of request behavior might be flagged as DoS activity by services used by Os

In order to address this, we probably should look to minimize the # of cancelled in-flight requests and more generally minimize the # of discovery requests sent by B (perhaps by caching entire OrchestratorInfo responses so that they can be re-used for a period of time across different streams from B without requiring an additional discovery request).

Spec for solution TBD.

[yondonfu]

It is a little hard to cache OrchestratorInfo messages to be used across streams right now because each OrchestratorInfo message is associated with an auth token which is meant to be used for an individual stream. The expectation is that there is a unique auth token per stream which would involve a GetOrchestrator call prior to the start of any stream. We could consider other updates here in the future that don't involve querying all known Os before the start of a stream, but for now I'm inclined to do the following which I think will help:

• Minimize the # of quick request cancellations that would cut a connection before TLS handshake completes
• Minimize the # of times that discovery needs to be run during a stream

Two issues created to address these two points are #1853 and #1852.

[yondonfu]

I think this should be addressed by the solutions documented in #2329 so closing.