Map instances to conductors using a consistent hashing algoritm

In the many discussions we've been having about how to run >1 ir-cond instance, some points have consistently been raised:
- we may need to route RPC messages to what ever conductor(s) is/are providing the TFTP environment for a given node
- we will need to inform Neutron of an instance:conductor mapping, so that it can appropriately forward DHCP BOOT requests (this depends on a separate BP to incorporate support for Neutron)
- we will need to update that mapping in Neutron when the mapped conductor becomes unavailable (this depends on "take over node" functionality in the conductor, which will be done separately as well)

One solution to this would be to implement a static scheduling service within Ironic, whose job is to manage the placement of instances. We have opted for a distributed architecture, and thus far avoided any static mappings.

A better option -- what this blueprint is proposing -- is to use a consistent hashing algorithm to associate instances to conductors. The number of buckets and number of replicas should be config options. Since Ironic already maintains a database table of conductor services, what drivers each conductor supports, and a heartbeat, this table can be used as a shared source-of-truth for the list of active/inactive conductors.

The details of this are being hashed out in this etherpad:

https://etherpad.openstack.org/p/IronicConsistentHashingForInstances