Cache state issue on traffic monitor

[jifyang]

Traffic monitor doesn’t show the correct state of a cache server in the following scenario:
First a cache server is deleted, then the same cache server is added.

The following is the detail:

1. initially three caches state are: "isAvailable": true
   [root@client ~]# curl http://monitor.cdn.com/publish/CrStates
   {
   "caches": {
   "mid-se-1": {"isAvailable": true},
   "edge-se-1": {"isAvailable": true},
   "edge-se-2": {"isAvailable": true}
   },
   "deliveryServices": {"ds": {
   "disabledLocations": [null],
   "isAvailable": true
   }}
   }
2. cache "edge-se-1" is deleted from traffic ops.
   [root@client ~]# curl http://monitor.cdn.com/publish/CrStates
   {
   "caches": {
   "mid-se-1": {"isAvailable": true},
   "edge-se-2": {"isAvailable": true}
   },
   "deliveryServices": {"ds": {
   "disabledLocations": [null],
   "isAvailable": true
   }}
   }
3. cache "edge-se-1" is added from traffic ops.
   [root@client ~]# curl http://monitor.cdn.com/publish/CrStates
   {
   "caches": {
   "mid-se-1": {"isAvailable": true},
   "edge-se-1": {"isAvailable": "unknown"},
   "edge-se-2": {"isAvailable": true}
   },
   "deliveryServices": {"ds": {
   "disabledLocations": [null],
   "isAvailable": true
   }}
   }
   The state of "edge-se-1" is "unknown" instead of true.

This is found in the commit "cec280b7887d0e0f8c843a004d5ed98d9b93b8c0". The current commit "5fe80041da59390fd402f9ca6ec6da1e4eabd8af" also has this issue.

[elsloo]

Confirmed this bug in the lab; it's definitely real, so this should be addressed in 1.6.0.

[elsloo]

Confirmed that this is a regression due to changes made in 1.5.x; we will fix this in master and backport the fix to 1.5.x.