fix(hpb): Deprecate multiple HPBs and fake-clustering

[nickvergessen]

☑️ Resolves

• Fix Deprecate "clustered HPB" mode #13011

This PR here will be backported.

Main-only follow up will be done to:

• Always use the first HPB
• Remove the conversation_clustering appconfig
• Remove UI option at add additional ones
• Throw on OCC command when trying to add additional ones
• Make the setup check an error

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not possible
• 📘 API documentation in docs/ has been updated or is not required
• 🔖 Capability is added or not needed

[nickvergessen]

/backport to stable30

[danxuliu]

Fine (and happy xD) to deprecated the conversation_cluster mode.

But I am not sure about forcing a single signaling server. If an HPB cluster is used, is it expected that a single signaling server is used in Talk? Or would it be possible to set up several signaling servers, so each participant ends in a random one, and then the signaling servers take care of exchanging the messages between them as needed?

The idea with that would be to avoid having a single point of failure in the signaling server cluster. @fancycode Could you clarify that? Thanks!

[nickvergessen]

If an HPB cluster is used, is it expected that a single signaling server is used in Talk?

Yes, that is what Jojo told me. You would specify a proxy in Talk in that case and that would take care of automatically load balancing

[fancycode]

If an HPB cluster is used, is it expected that a single signaling server is used in Talk?

Yes, that is what Jojo told me. You would specify a proxy in Talk in that case and that would take care of automatically load balancing

Right, the load-balancer in front can easily determine which signaling server(s) are available and distribute the requests across them. Having a list in Talk would require to also implement the checks there and handle all sorts of cases if the list of available servers changes (i.e. how to notify clients to now use a different server, etc.).

[fancycode]

The idea with that would be to avoid having a single point of failure in the signaling server cluster. @fancycode Could you clarify that? Thanks!

Of course the load-balancer / proxy in front should be setup so that it's redundant / highly-available. But this is out of scope for Talk or the signaling server. If your setup is so large that you need a clustered signaling server, you should have ways to run a HA frontend proxy / load balancer.

[danxuliu]

@fancycode Thanks for the information!

[fancycode]

lgtm with a wording suggestion