feat: peer management on pubsub via callbacks

[kentquirk]

Which problem is this PR solving?

• Implement the current peers system using a pubsub model for peers
• Uses the current pubsub system that uses callbacks

Short description of the changes

• Add start/stop to pubsub so it can become injectable
• Fix the mock and existing implementations
• Implement pubsub peers using the new pubsub system and generic.SetWithTTL
• Add a few tests
• Update config metadata
• delete legacy redis peering
• make it more idiomatically injectable
• do all the things to make injection work everywhere

closes #1201

[VinozzZ]

I'm more inclined to remove the existing redis peer management logic. Couple reasons that comes to mind:

• since the pub/sub implementation is still using redis, having it as a separate config option feels a bit confusing for me
• does that mean stress_relief also needs a type option so that customers can choose to stay with the existing stress relief mechanism?
• I can't think of a scenario that customers will want to stay with the existing redis implementation if pub/sub system ultimately enables scaling without loosing data.
• it would be nice that we can just have one redis package in refinery instead of maintaining two implementation

[VinozzZ]

How about a test with multiple peers that can get correct number of peers and the callback functions are called when a peer joins or leaves the cluster?

[kentquirk]

I've been trying to write that test, and it's not real easy to run multiple peers on the same machine. I think it's possible, but it might need some gymnastics to make it happen.

Because I'm going on vacation now, I'm going to merge this so it doesn't get stale while I'm gone. We can look at that test another time.