Support multiple replicas with a single leader

[stigok]

Problem

• The GitHub API has rate limiting implemented that must be carefully respected to avoid lock-out. When multiple replicas are all reading from the API the chances of this happening increases linearily. If the replicas are aware of each other, a leader can be elected to take care of API reads before replicating the results to the other replicas.
• When multiple replicas are behind a load balancer, if webhooks are implemented as in Update cache using Github webhooks #71, only a single member will receive the update. The webhook payload or the resulting side-effects of the event must be replicated to the other replicas.

Proposed solutions

• Implement redis client code to connect to a redis cluster for both storage and leader election.
  • Introduces an extra moving part/system
• Embedded database and/or clustering mechanism
  • Maybe all we need for this alternative https://github.com/hashicorp/memberlist

Goal

• Limit the amount of complexity of the selected solution as much as possible

[stigok]

Raft seems very good, but also seems very complicated. Would probably suffice to implement some poor mans leader-election through memberlist instead. We don't need to be 100% sure we're the leader -- we just need to reduce the chance of more than one client querying the GitHub API at a time.