Move USER_IP replication command to a separate redis pub/sub channel.

[erikjohnston]

Currently all replication commands get sent to all workers via the single pub/sub stream. This can be a lot of traffic, roughly evenly split between USER_IP and RDATA commands.

However, only a subset of workers care about USER_IP commands, and the rest just immediately drop them on receipt:

synapse/synapse/replication/tcp/handler.py

Lines 412 to 423 in e3a49f4

	if self._is_master or self._should_insert_client_ips:
	# We make a point of only returning an awaitable if there's actually
	# something to do; on_USER_IP is not an async function, but
	# _handle_user_ip is.
	# If on_USER_IP returns an awaitable, it gets scheduled as a
	# background process (see `BaseReplicationStreamProtocol.handle_command`).
	return self._handle_user_ip(cmd)
	else:
	# Returning None when this process definitely has nothing to do
	# reduces the overhead of handling the USER_IP command, which is
	# currently broadcast to all workers regardless of utility.
	return None

Instead of sending them to the same pub/sub channel, we should send USER_IP commands to a separate channel that is only subscribed to by workers that need them.

This would involve changing the stream name we send the USER_IP command to here:

synapse/synapse/replication/tcp/redis.py

Lines 219 to 221 in e3a49f4

	self.synapse_outbound_redis_connection.publish(
	self.synapse_stream_name, encoded_string
	)

And change the channels we subscribe to:

synapse/synapse/replication/tcp/redis.py

Line 121 in e3a49f4

await make_deferred_yieldable(self.subscribe(self.synapse_stream_name))