Split development and test Redis databases

What does this Merge Request do and why?

In gitlab!63040 (merged), I introduce a new spec that has the use_clean_rails_redis_caching option. This basically runs flushall around the test, deleting everything in it (I've since updated the test suite so it uses flushdb instead).

In the GDK, this means that you lose your session, as it's currently configured. It's not the first test that does this, but I have been running it locally in a tight loop, and it's annoying 😅.

I also had a struggle in the same MR before adding per-test isolation of the redis database, because cache keys set in the development environment were bleeding over to the test environment. Using a separate Redis database for each environment means that this will no longer happen.

Additionally, in CI, we configure four different redis databases for the tests - cache, queues, shared_state and trace_chunks. Having this be different between GDK and CI can cause tests to pass locally while failing in CI, or vice-versa.

This MR configures 8 different redis databases in GDK, providing full isolation across the [environment, cluster] axes. Backward compatibility is provided by using database 0 for development shared_state, but we expect users to do a gdk restart after a gdk reconfigure anyway, which wipes the redis databases.

We need to point Workhorse at the shared_state cluster; this is done by modifying the workhorse config.toml for development, and automatically by rspec, reading redis.shared_state.yml, for test.

We do have one area where this doesn't provide isolation - redis pubsub support. That ignores database number entirely. This could be managed by using a different redis process per [environment, cluster], but that starts to get very complicated. In #818 (comment 596839157) we decided this approach is enough of an improvement over the status quo to justify a merge.

Merge Request checklist

• This change is backward compatible. If not, please include steps to communicate to our users.
• Tests added for new functionality. If not, please raise Issue to follow-up.
• Documentation added/updated, if needed.
• gdk doctor test added, if needed.
• Add the ~highlight label if this MR should be included in the CHANGELOG.md.

Closes #818 (closed)