Support running multiple media repos.

[erikjohnston]

This requires a new config option to specify which media repo should be responsible for running background jobs to e.g. clear out expired URL preview caches.

This is a bit of an icky way of doing it, though I think somewhat consistent with how we do worker configs currently. There are a couple of other options here:

1. Use distributed lock based on Redis, this is a bit difficult due to redis not having native support for this (the documentation suggests using a thing called Redlock, but the fact that Kleppman thinks its unsound is not exactly confidence inspiring). An argument could be made that we're probably will need to do something like this at some point though.
2. Change the way we do our config to instead list which instances are responsible for media operations in the main config and chose the first to be responsible for running the background jobs. This has the advantage that a) its impossible to mess up and b) its similar to how we specify which worker is responsible for event persistence.

TBH though, it feels like we shouldn't block this behind trying to implement a distributed lock or changing how we configure workers

[clokep]

I think the implementation looks sane, I don't have an opinion about using a config option vs. other approaches.

[clokep]

Removing the review flag on this as Rich asked for some changes in #synapse-dev:matrix.org.

[erikjohnston]

Ok, this now uses a scheme where you specify which instance runs the background jobs. Unfortunately, to support backwards compat we can't require it when using split out media repo and so if you don't specify the config option it'll still run on all of them.

[clokep]

I think the backwards compatibility is OK since...you shouldn't have been running multiple in the past anyway, so hopefully people will read the docs on how to do it.