Geo proxy: disable watching Redis / polling internal API if Geo is not enabled

As a follow-up to !86468 (closed) and #350202 (closed), considering that enabling Geo is most likely going to require a restart, we could add an improvement to short-circuit the logic and disable the continuous Redis watching/internal API polling.

There are some more notes in the thread at !86468 (comment 953600477), but the key parts are:

Mike:

Another thought: Maybe we could make FOSS (and EE without Geo) actively set something or return some particular data such that Workhorse can distinguish between Geo primary vs no Geo at all. In that case, Workhorse can kill the loop or whatever the terminology would be, since upgrading to EE or configuring Geo for the first time requires reconfigures and restarts.

Me:

We need to care about the following cases:

  • "proxying => should not proxy":
  • secondary with proxying => primary - I don't think needs a restart?
  • secondary with proxying => disabling proxying (or changing URL etc, until the separate URLs FF is always enabled) - might not need a restart (changing the URL of the primary for example)
  • "not proxying => should proxy"
    • primary => secondary - would probably need a restart (at least we always recommend to, per the steps of demoting an old primary to a secondary)
    • secondary with disabled proxying => secondary with proxying - would not need a restart

So it sounds like we could disable looping on non-Geo or primary sites (with the primary => secondary consideration). One other scenario could be non-Geo => secondary with proxying, but I don't think that could happen without a restart either?

Mike:

I think it is acceptable to poll on a Geo primary, especially if it makes the conditions simpler. Maybe it will be necessary anyway in the future, when we try to make failover easier.

I think we want Workhorse to know that Rails actively communicated Geo configuration information after Workhorse started.

Related to that, we may need to watch out for a case where the key is previously set and persisted across Geo configuration changes but Rails hasn't started yet.