Allow composition of ACL policies

[gizmoguy]

From talking to @loriscn12 he suggests we should add the ability to compose a superset ACL from many other ACL rules.

So currently if we want reduce duplication of ACL rules we can apply multiple ACLs to ports like so:

dps:
    sw-1:
        1:
            acls_in: ["drop_smtp", "drop_dhcp"]

This works, but another idea is to allow users to create an ACL which is a composition of other ACLs:

acls:
    drop_smtp:
        - rule...
    drop_dhcp:
        - rule...
    drop_access
        - include_rules: drop_smtp
        - include_rules: drop_dhcp

Initially, this seems simply like another way to doing the former, however with the ability to compose an ACL rules from a subset of other ACLs we could do interesting things like creating templated ACLs from additional information we learn about ports (such as 802.1x information). Maybe we could have something like:

acls:
    drop_smtp:
        - rule...
    drop_dhcp:
        - rule...
    brad_access:
        - rule...
        - rule...
    drop_access
        - include_rules: drop_smtp
        - include_rules: drop_dhcp
        - include_rules: {{ 8021x_username }}_access

[KitL]

So there are two ways currently we can configure ACLs:

acls:
    drop_smtp:
        - rule: {...}
    drop_dhcp:
        - {...}

I think the general consensus was that we should be moving to the second format because it is less verbose, and up until now the rule part has been pointless since the only thing that could ever be configured in this list was an acl rule.

So the obvious way to configure this based on that second approach is like this

acls:
    drop_smtp:
        - {...}
    drop_dhcp:
        - {...}
    brad_access:
        - {...}
        - {...}
    drop_access:
        - "drop_smtp"
        - "drop_dhcp"
        - "{{ 8021x_username }}_access"

I think the issue would be is if in the future we expect that there might be a third way to configure an acl, I am not sure how we would do that. Using the single element dict approach means we can have infinite different ways to extend this config. But on the other hand saying a dict is a rule and a string is a reference makes the config cleaner and more consistent.

Or for consistencies sake perhaps we should move back the other way, and always use a single element dictionary whenever we have a list of configuration blocks (eg. for LLDP).

Can anyone think of a reason me might want a third way to configure an acl rule?

But in the mean time it's pretty trivial to support both approaches.