Improve handling of routes with path

[gberche-orange]

cloudfoundry routes include an optional path, see http://docs.cloudfoundry.org/devguide/deploy-apps/routes-domains.html#routes

overlapping routes may prevent autowakeup wildcard route to receive traffic from stopped app

• given the following apps:

$cf a 
name                    requested state   instances   memory   disk   urls
microservice-ui           started           2/2         64M      1G     app.cfapp.io/ui
microservice-backend      started           2/2         1G       1G     app.cfapp.io

• when microservice-ui app gets put to sleep
• then traffic to microservice-ui app's routes should trigger autowake up of the corresponding app.

Due to the current implementation leveraging wildcard routes (as a temporary workaround until #203 gets unblocked), and the precedence rules of routes in gorouter the orphan traffic currently does not reach the autowakeup app, and instead is routed to the microservice-backend

autowakeup ignores the route path and may wakeup irrelevant app

When autowake up receives traffic for stopped app and tries to identity the right to start, it ignores the path part and randomly select one app matching the hostname

See https://github.com/cloudfoundry-community/autosleep/blob/e3821106f791b82acdeef535f4d87434dc5e34ea/spring-apps/autowakeup-proxy/src/main/java/org/cloudfoundry/autosleep/ui/proxy/WildcardProxy.java#L127-L127

alternative solutions

exclude apps with overlapping routes from auto-enrollment

• given the following unenrolled apps:

$cf a 
name                    requested state   instances   memory   disk   urls
microservice-ui           started           2/2         64M      1G     app.cfapp.io/ui
microservice-backend      started           2/2         1G       1G     app.cfapp.io

• when the autosleep service scans the apps
• then the apps don't get enrolled

  manages "app clusters (associated to a hostname and all paths)" instead of individual apps

• given the following enrolled apps:

$cf a 
name                    requested state   instances   memory   disk   urls
microservice-ui           started           2/2         64M      1G     app.cfapp.io/ui
microservice-backend      started           2/2         1G       1G     app.cfapp.io

• when the microservice-ui app reaches its inactivity threshold
• and when the microservice-backend app reaches its inactivity threshold
• then both microservice-ui and microservice-backend apps gets put to sleep