TR should check for closest cache group because using Maxmind Geolocation

Problem Statement:
If all caches in the primary cache group are unavailable, our goal is to provide a backup routing policy for RFC1918 clients.

When client IP is an public Internet IP, the current backup policy is to assign the client to the geographically closest cache (Distance = MaxMind Geo Lat/Long - configured CG lat/long).

With Jeff's proposed fix below, instead of going to the geolocation provider, TR would find the cache group closest to the CZF "hit" cache group.

From Jeff Elsoo:
There's a small logic gap in the existing algorithm around cache
location selection and I think if we fix that (two line change), we
should be better off all around. I think the only time we'd ever want
to go to the geolocation provider is in the event of a miss on the
CZF, so as long as we have a hit there, we should find the cache group
closest to that hit location that has available caches. This would
automatically provide the "backup" cache group concept, and has the
added benefit of doing this selection dynamically based on the state
of the CDN.

See this to get an idea of what I mean: http://apaste.info/u3PQo

Obviously we'd need to test this to ensure we don't break other functionality.

dev@ Discussion Thread: https://lists.apache.org/thread.html/b033b3943c22a606370ad3981fa05fb0e7039161b88bbc035bc49b25@%3Cdev.trafficcontrol.apache.org%3E