Static sec-group ranges for "all internet" access use-case

[gberche-orange]

In addition to supporting dynamic ASG derived from filtered credentials, there are use-cases for creating static ASG definitions regardless of the returned credentials.

One use-case, is a static-cred-broker that will provide an "all internet" service, possibly returning empty credentials.

Scenario 1:

Given a sec-group-filter deployed with the following specific configuration:

cf set-env always-apply-sec-group-definitions ' [ { "protocol": "tcp", "destination": "10.0.11.0-10.0.11.255", "ports": "80,443", "description": "Allow http and https traffic from ZoneA" },  { "protocol": "tcp", "destination": "10.0.12.0/24", "ports": "80,443", "description": "Allow http and https traffic from ZoneB" } ] '

When a filtered broker returns the following binding response (e.g. a static-cred configured to return an empty binding response)

{ }

Then the following ASG is created and bound to the corresponding application:

[
 { "protocol": "tcp", "destination": "10.0.11.0/24", "ports": "80,443" } ,  
 { "protocol": "tcp", "destination": "10.0.12.0/24", "ports": "80,443" }
]

Optional scenario 2:

When a filtered broker returns the following binding response (e.g.

{"uri":"https://developer-tripadvisor.com/content-api/"}.

with developer-tripadvisor.com resolving to 23.21.145.5

Then the following ASG is created and bound to the corresponding application:

[
 { "protocol": "tcp", "destination": "23.21.145.5/32", "ports": "443" } ,  
 { "protocol": "tcp", "destination": "10.0.11.0/24", "ports": "80,443"  } ,  
 { "protocol": "tcp", "destination": "10.0.12.0/24", "ports": "80,443"  }
]

Rationale for scenario 2 is to simplify the implementation (previous behavior and existing specs are not affected). CF supports redundant security groups declarations.