Improve Action Cable DB load balancing strategy

In !115828 (merged) we allowed some Action Cable operations to use DB replicas but actions executed in response to a subscription trigger always use the primary.

This is done because when a subscription is triggered, that is usually due to a newly updated record that we want to broadcast. Those receiving the broadcast should query up-to-date data so that the newly updated information is sent back to the subscribed client.

This strategy can be improved further by changing it so that it only queries the primary if there are no up-to-date replicas. Similar to the :sticky strategy we use for Sidekiq.

We can include the current WAL location of the primary as part of the broadcast payload. And then the subscribers can check this and select an appropriate replica or fallback to the primary.