Subscribe every WebSocket client to a unique topic, by default under
zeek/cluster/websocket/client/<identifier>/
Add tests that verify that WebSocket clients receive messages on these topics
even if they didn't explicitly pass them in their handshake message.
This is somewhere between feature and bug fix. It aids the ZeroMQ backend
implementation: A WebSocket client that doesn't provide any subscriptions
and immediately starts publishing would discard events until receiving
other nodes subscriptions from the central XPUB/XSUB proxy. ZeroMQ does sender
side topic filtering. When using subscriptions, the client waits until
its own subscriptions are returned from the central XPUB/XSUB proxy,
thereby also learning about other node's subscriptions.
Also, make the no-subscriptions.zeek test use 32 clients sequentially to
trigger potential issues more quickly.
Limit the number WebSocket events queued from external clients to
dispatcher instances to produce back pressure to the clients if
Zeek's IO loop is overloaded.
Explicitly notify the internal thread about the shutdown via the
inproc socket pair. This ensures that the internal thread processes
all previous messages on the inproc socket before terminating.
This fixes the scenario where a backend is created, a few messages published
and then immediately terminated as can be done with WebSocket clients.
Previously, some of the messages published might have still been in the
inproc socket's queue and were simply discarded.
Adds the same test for Broker and ZeroMQ backends.
These test were very sensible to the speed at which ZeroMQ distributes
subscriptions in the cluster and showed to be unreliably when testing with
zeek/btest#113.
The main fix here is to have individual WebSocket clients subscribe to unique
topics, e.g /test/client-0 and /test/client-1, instead of just a shared topic.
This ensures the WebSocket handshake completes only when they observed their
own subscriptions and not prematurely when observing the shared topic.
This seems mainly relevant for tests: In the real world one shouldn't
rely on subscription visibility - you miss messages if you're too late
to the party.
