Remove clustering from streaming API

[ThisIsMissEm]

This PR supersedes #23518

As part of updating that PR, I've also started to clean up a bit of the environment variable loading, which will help with getting the code to a more testable state.

I am debating whether we should add a check for STREAMING_CLUSTER_NUM being set, and if so, print a log line with documentation as to how to move to using nginx for streaming clustering.

The PR on the documentation repository with instructions for evolving configurations to let the load balancer handle the clustering of streaming can be found at mastodon/documentation#1207

[ThisIsMissEm]

@Gargron a change that we may wish to consider is changing from using PORT, SOCKET and BIND as environment variables to using STREAMING_* as a prefix for them, as streaming runs on a different port/socket to rails, and this can be configured via dotenv. This would also make the configuration documentation a bit clearer.

[Gargron]

One point to consider is that at least on Puma's side, dotenv is loaded too late for PORT, BIND and SOCKET to have an effect if defined in the dotenv file, so it's something we expect people to inline in the command call or set in systemd Environment=. Also, with these variables it makes more sense to define them process-by-process rather than in one file because you might have many parallel processes you don't want to contest for the same port. Are there situations where it makes sense to put those variables in the dotenv file?

[ThisIsMissEm]

One point to consider is that at least on Puma's side, dotenv is loaded too late for PORT, BIND and SOCKET to have an effect if defined in the dotenv file, so it's something we expect people to inline in the command call or set in systemd Environment=. Also, with these variables it makes more sense to define them process-by-process rather than in one file because you might have many parallel processes you don't want to contest for the same port. Are there situations where it makes sense to put those variables in the dotenv file?

Yeah, so, I'm suggesting that we just make them explicit as to what they're for, not so much that you put them in dotenv (that's entirely optional).