@Transition(to = "OFFLINE", from = "ERROR")
  public void onBecomeOfflineFromError(Message message, NotificationContext context) {
    boolean shouldTransition = shouldTransition(message);
    String partitionName = message.getPartitionName();
    logger.info("Partition {} in resource {} is becoming OFFLINE from ERROR, Should Transition? {}", partitionName,
        message.getResourceName(), shouldTransition);
    if (shouldTransition) {
      partitionStateChangeListener.onPartitionBecomeOfflineFromError(partitionName);
    }
  }
Ambry is currently going through the process of reconstructing resources. We used to assign partition ids to several
resources, even if those partition ids belong to the same clique. Now we are trying to gather all the partition ids
of the same clique to one resource.

In doing so, we should inevitably 1. duplicate all the partition ids with a different resource 2. remove the old
resources.  The issue is that resource doesn't really matter in Ambry. Resource is a structure required by Helix.
Ambry has a flat structure. This structure starts with a cluster. Under this cluster, it has partitions. If we
duplicate all the partition ids with different resources, we would force these partitions to go through state
transition twice. And by removing the old resource, we would effectively force all the partitions to go through
downward transition to DROPPED state. We have to make sure that frontend and server would be able to deal with both
situations.

Current resource names are all numeric numbers starting from 0. The new resource names will be numeric numbers as
well, but it will be starting from a much higher number, like 10000. So we can easily find the new resource by just
comparing the resource names.

When we eventually remove old resources, all the partition ids under those resourced would have to go through state
transition to become DROPPED in the end. A dropped partition means all the data will be removed, we don't want any
partition to remove data. So in state transition, we have to make sure after we add new resources, the state
transition messages from the old resources would be ignored and won't take effect anymore.

Since in server we honor new resource over the old resource, we have to do the same thing in the clustermap.

We have three implementations of {@link PartitionStateChangeListener}, StorageManager's implementation, ReplicationManager's
implementation and StatsManager's implementation. Most of the those implementations are fine with going through state
transition multiple times and generate the same result, except for ReplicationManager. When transitioning from standby
to leader and from leader to standby, replication manager would change the leader pair. If different replicas are chosen
to be leader in different transition, then we would have multiple leaders. But this is fine, since replication manager
use this leader pair information for cross-colo replication. The worst case is that we have more than one replicas doing
cross-colo data replication.

In order to make sure we don't allow state transition messages for old resource to go through, we will leverage clustermap.
When new resources are created, clustermap would receive this update and replace the resource name for all the partitions.
StateModel has to compare the resource name in transition messages with the resource name in clustermap. Here are the
four cases StateModel has to deal with.
1. New resources are created, but clustermap hasn't updated the resources yet
2. New resources are created, and clustermap has the up-to-date resources
3. Old resources are removed
4. Hosts that were unavailable when old resources were removed, now is waking up and deal with state transition messages
   for both new and old resources.

For case 1, if the resource name from transition message is greater than the resource name from clustermap, then allow the transition
For case 2, resource name from transition message is included in the clustermap.
For case 3, resource name from transition message should be less than the resource name from clustermap, so don't allow the transition
For case 4. clustermap has the new resource name, and old resource name is less than the new ones, so don't allow the transition
            for old resource names, but allow transition for new resource names.
ambry-clustermap/src/main/java/com/github/ambry/clustermap/AmbryPartitionStateModel.java