Readme Improvment regarding concurrent requests

"But will it scale?" is an important concern for everyone that considers this gem, since ActionCable itself is pretty bad (unfortunately) when we hit thousands of subscribers (as AnyCable benchmarks shows).

Right at the beginning of the readme it states that "MessageBus can handle thousands of concurrent long polls on all popular Ruby webservers", but I wish to improve it with some numbers so we can have a ballpark idea of how many concurrent connections it could actually handle.

And honestly I'm ignorant on how exactly that can be done! If it uses (by default) a long-polling stategy with streaming which keeps "the connection open for the configured long-polling interval (25 seconds by default)" (I'm quoting from the README), doesn't it mean that for every subscriber there will be an open connection that remains open all the time?

If you have a Puma server with 5 threads and 2 workers, can't it only handle 10 concurrent requests? By "the connections remain open during the long poll intervall" I assumed that thread would not be available for responding to any other requests (like, for instance, if it was a regular rails request that took very long to respond - the thread is stuck until that request finishes).

I commit myself to make a pull request to improve the readme on this part, but of course I need to understand how this works first :)

(I read the how it works section, but couldn't find these answers there).

Start with the README’s opening scalability claim and its “how it works” section, then investigate how the default long-polling and streaming behavior uses Ruby/Rack server threads and workers. Document supported concurrency figures and clarify whether long-polling connections prevent Puma workers from serving other requests.