Move schema_cache calls to replicas even when stuck to primary

What does this MR do and why?

This expands on the approach in !116211 (merged) that moved schema_cache calls to the replicas, which you can see in this Thanos query:

The left side of the graph is before !116211 (merged) was deployed, no calls were going to replicas, then the first small bump in queries against the replicas correlates to the deploy to canary, and the large spike against the primary correlates to the deploy to production, then you can see an improvement as the number of calls to the replicas increase, but to the right side of the graph we continue to see some spikes occurring against the primary.

This MR will move schema_cache calls to the replicas even when the current load balancing session has been stuck to the primary by a write. This should be safe since the schema_cache calls do not need to occur in transactions with writes.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.