This interface is intended to allow abstraction between a charm offering a service and one offering a reverse proxy.

All relation states should check for 'triggered' state to be sure it is a realation based event.

Expected flow:
 - Requires:
   - when 'ready' and when_not 'configured' call the configure fucntion to provide reverse proxy request information
 - Provides:
   - when 'changed' apply self.config to the configuration. *This is a list
     of configurations to apply*
   - return a feedback about the config via the set_cfg_status function
 - Requires:
   - if cfg_status is a failure interface will log any provided status and fail
   - if cfg_status is a success a success will be logegd via 'INFO' and no other state is applied

Departed:
 - Provides:
  - when 'departed' remove self.config from the configuration

Proxy Configuration Keys:
 - mode: (Optional) set 'tcp' or 'http' routing, defaults to 'http'
 - urlbase: (Optional if subdomain is provided) the base url to redirect to his charm, including leading /
 - acl-local: (Optional) restrict access to local ip address ranges for this backend
 - rewrite-path: (Optional) remove the urlbase from the path 
 - subdomain: (Optional if urlbase is provided) a subdomain to redirect to this charm
 - external_port: the external port to listen on
 - internal_host: the internal host to redirect to
 - internal_port: the internal port to redirect to
 - group_id: (Optional) all relations with a matching group id will share the same server pool. urlbase, subdomain, and external_port should match on all members of the group
 - proxypass: (Optional) set Forward-For and Forward-Proto headers
 - ssl: (Optional) Connect to the backend via ssl regardless of the port
 - ssl-verify: (Optional) Boolean, set to True to check SSL certs. False will not check
 - check: (Optional) perform port availability check, defaults to True set False to not check