include_system_packages is True and may obscure dependency isolation in venvs

The following confirms and details the current state of the two options, which are essentially at odds with one-another in terms of declaring dependencies in a sane way.

ie. When using a venv, we should never include system packages.

#### All src (reactive) OpenStack charms:
ubuntu@beisner-bastion:~/git/release-tools⟫ find -type f -name layer.yaml | sort
./aodh/src/layer.yaml
./barbican-softhsm/src/layer.yaml
./barbican/src/layer.yaml
./ceph-fs/src/layer.yaml
./designate-bind/src/layer.yaml
./designate/src/layer.yaml
./gnocchi/src/layer.yaml
./keystone-ldap/src/layer.yaml
./manila-generic/src/layer.yaml
./manila/src/layer.yaml
./neutron-api-odl/src/layer.yaml
./openvswitch-odl/src/layer.yaml
./tempest/src/layer.yaml

#### Those which take a stance on use_venv and/or include_system_packages:
ubuntu@beisner-bastion:~/git/release-tools⟫ find -type f -name layer.yaml | sort | xargs egrep "system|venv"
./aodh/src/layer.yaml: use_venv: True
./aodh/src/layer.yaml: include_system_packages: True
./barbican-softhsm/src/layer.yaml: use_venv: true
./barbican-softhsm/src/layer.yaml: include_system_packages: true
./barbican/src/layer.yaml: use_venv: true
./barbican/src/layer.yaml: include_system_packages: true
./designate/src/layer.yaml: use_venv: True
./designate/src/layer.yaml: include_system_packages: True
./gnocchi/src/layer.yaml: use_venv: True
./gnocchi/src/layer.yaml: include_system_packages: True
./keystone-ldap/src/layer.yaml: use_venv: True
./keystone-ldap/src/layer.yaml: include_system_packages: True
./manila/src/layer.yaml: use_venv: true
./manila/src/layer.yaml: include_system_packages: true
./neutron-api-odl/src/layer.yaml: use_venv: True
./neutron-api-odl/src/layer.yaml: include_system_packages: True
./openvswitch-odl/src/layer.yaml: use_venv: True
./openvswitch-odl/src/layer.yaml: include_system_packages: True

#### Those which do not declare either, leaving it up to version chance:
ceph-fs
designate-bind
manila-generic
tempest

Reference, some recent default behavior changes:

https://github.com/juju-solutions/layer-basic/pull/105/files#diff-8d6683ea7efc34cfd86d2121c50b8acbL8

https://charmsreactive.readthedocs.io/en/latest/layer-basic.html#layer-configuration

In an interesting and relevant twist, coincidentally the same day we're dealing with pip >= 10.0 and python-apt on a separate bug which affected test execution environments (bug #1760720):

At least in the tempest charm, if I leave use_venv True and set use_system_packages False, I get apt import errors at charm run time. The charms are clearly leaning on the fact that some system-installed libraries are installed outside of the virtualenv (via debs in this case). Lines, blurred. Wires, crossed.

This is just one example, but it is a clear example of how we have missed fully declaring dependencies from a pure python standpoint.

Further ideas, debate, conversation are of course welcome.

The charm uses:

options:
  basic:
    use_venv: True
    include_system_packages: False

Thus, this is resolved.

The src/layer.yaml now contains:

options:
  basic:
    use_venv: True
    include_system_packages: False

Thus this is fixed released now.

The charm now includes in the layer.yaml:

options:
  basic:
    use_venv: True
    include_system_packages: False

Therefore this is fixed released.

The charm is no longer being maintained.

Marking as invalid as the charms now use venvs and are not dependent on system packages. charms.openstack works in this environment; thus there is nothing to do.