Add separate workflow for testing on Python 3.6 as this
requires an older Ubuntu release.

Fixup unit tests for compatibility with newer versions of mock.

Drop latest/stable functional test targets - this is actually
2.9.x of Juju and is already covered by the 2.9 targets and we
want to avoid suddenly picking up a new Juju version because
this will break with the new approach to version alignment in the
Python module for Juju.

Drop 2.8 functional test target - its broken and we don't really
support this version any longer.

Fixup iptables forwarding issues from LXD containers with a flush
and re-create of rules.

(cherry picked from commit 9277a94)

Juju is pinned to <3.0 earlier. This
patch pins the juju version to <3.2
so that libjuju 3.1 version is used.

Modified run_on_unit to wait for
completion and update results based
on output.

Update channel in github workflows to use Juju 3.1.

Drop --no-gui flag usage as this is the default now.

Update model configuration default-series to focal.

Drop --classic flag for Juju installation.

When juju is strictly confined, random temp directories under /tmp
are not accessible - render any templated bundle files under $HOME
instead as this should be readable.

python-libjuju is released in lockstep with juju, hence if zaza uses a
2.9 controller, it should use libjuju-2.9.x, for a 3.1 controller it
should use libjuju-3.1 and so on.

This change makes libjuju an extra, which means depending on the juju
controller version will be used the right extra should be passed at
install time.

For juju-2.9:

    pip install zaza[juju-29]

For juju-3.1:

    pip install zaza[juju-31]

Summary of changes:

- Add juju-3.2 to the github workflow matrix
- Add 'juju-32' extra to install juju-3.2.x

This forces tox to install the zaza python package and honor the
'extras' defined.

By default depend on 'juju' (no pinning), the pinning only comes into
place when an explicit extra is passed.

This makes the extras effectively nothing more than a pinning alias,
basically `pip install juju<3.0 zaza` becomes equivalent to `pip install
zaza[juju-29]`.

Value of the Code key in the returned Dict is str in master branch. However
while trying to get compatible with juju 3.x series it became int. Now it is
not conforming to the function signature. Also there are usages in some
tests so it reverted back to str.

Pinning via constraints is left to downstream consumers.

By default libjuju 2.9 will be used, this can overriden by passing the
PIP_CONSTRAINTS environment variable

Examples:

    PIP_CONSTRAINTS=./constraints-juju31.txt tox -e pep8 --recreate

This allows running functional tests with different versions of juju

The testing runners use Python 3.8 (Focal), hence no need to keep py36
alive.

Juju 3.x replaced the `series` status key with a `base` key that
consists of Distribution type and version number.

To avoid maintenance burden we add a Launchpad module that
implements functions to look up available Ubuntu series data.

Update the `get_machine_series` helper function to determine
Ubuntu series from `base` when no `series` key is available.

Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>

This file aims to hold the default version of juju that it's expected
charms to be tested with. It helps to serve as a sane default for
tox.ini

The juju snap can't run programs that are outside the snap due to the
confinement restrictions