Mapping datacenter name to an id.

[xiahome]

Each datacenter currently has a String representation, e.g., DC1, which is specified when making the cluster. Because of the reason specified in #636 , an id in short needs to be generated for each datacenter. Datacenter id will be used in both put and get path for a blob.

1. Put a blob: the router is the component to perform the put blob logic. When a put is successful, the router will get the id of the datacenter (usually the local datacenter), by calling getDatacenterIdByName(dcNameForPut), and embed the datacenter id into the blob id as proposed in #636 .
2. Get a blob: if getting the blob in the local datacenter of the router fails, the router can extract the id of the original datacenter for the blob, and get the datacenter name by calling getDatacenterNameById(dcIdInBlob). Then, the router can issue a get request to the original datacenter, avoiding fetching the blob from other datacenters.

Therefore, getDatacenterIdByName and getDatacenterNameById are needed. ClusterMap interface is a natural place to define these two methods, because datacenter is a cluster-wide component under the awareness of a cluster map. Each implementation, so far StaticClusterManager, HelixClusterManager, and CompositeClusterManager, implements the mapping between datacenter name and datacenter id.

There are two approaches to make an id for a datacenter name:

1. Have the cluster map creator to assign an id to each datacenter. For example, in the hardware layout json file, an additional field is created to specify an id for each datacenter;
2. The id is generated internally. This can be done by hashing the datacenter name into a short id.

The second approach is more favored, for the following reasons:

1. There is no need for the cluster map creator's to be aware of datacenter id. The id is purely internal, but requires to be cluster-wide unique.
2. It requires attention from the cluster map creator to make the id unique when adding or updating datacenter.

This ticket is created to track the work of adding the feature of mapping datacenter name to id, and vise versa.

[vgkholla]

The put path is done in #794

[vgkholla]

For GETs and DELETEs, the following can be done

1. Start by prioritizing the "originating" datacenter for sending cross colo requests. -- originating datacenter is the local DC. Then sort cross colo in any order -- originating datacenter is no longer present. Then sort cross colo in any order
2. Once 1) is ready and merged, discuss and decide when to stop asking more datacenters -- if "originating" datacenter replicas all report NOT_FOUND, should we continue? It is possible that the "originating" datacenter is undergoing reconstruction after a full DC destruction. In that case, it is no longer reliable. So it might make sense to continue. However, this event is rare. -- if any of the "originating" data center replicas report server errors or if they are down, then the operation MUST continue. The OperationTracker might need to be told whether the error is a server error or not.

To deal with 2.1, a middle ground might be to have a config that tells the OperationTracker whether to continue or not.

To do 1), a new ClusterMap API is required that can translate a data center ID into a datacenter name which should then be fed into the OperationTracker

I started some really initial work on this which is here.