Instead of being "collection already exists" it returns "collection
'foo' already exists". But in both cases they end with "already exists",
so we'll live with it and just move on.

CI: bring 2.2 acceptancetests up-to-date juju#8293

Ensure 2.3 branch is up to date with acceptancetests changes from develop.

The new ci-run will be testing from in tree, so the tests and scripts need to be up to date.

CI: bring 2.3 acceptancetests up-to-date

Ensure 2.3 branch is up to date with acceptancetests changes from develop.

The new ci-run will be testing from in tree, so the tests and scripts need to be up to date.

…ditConversationEventually

Use testing clock in TestLoginAddsAuditConversationEventually

## Description of change
TestLoginAddsAuditConversationEventually used wallclock which caused test failure when the test was executed 'at the tick', this PR fixes it.

## QA steps
Only a test fix.

## Bug reference
https://bugs.launchpad.net/juju/+bug/1742697/

There was probably a transition period where this was useful, but we
actually don't want to be running juju-mongodb on Xenial.
See https://bugs.launchpad.net/juju/+bug/1743901 where we fell back to
juju-mongodb because there was a temporary problem with the archive
mirror. But eventually juju-mongodb3.2 was found and juju started trying
to use that instead of the old mongo 2.4, and that just breaks
everything because it tries to launch the new mongo on the old database.

On Trusty, we shouldn't ever be installing juju-mongodb3.2, so we just
always pick an exact version to install. We also remove a bunch of
series that we don't actually support anymore.

…-1743901

On Xenial, we don't actually want to fall back to juju-mongodb.

## Description of change

There was probably a transition period where this was useful, but we
actually don't want to be running juju-mongodb on Xenial.
See https://bugs.launchpad.net/juju/+bug/1743901 where we fell back to
juju-mongodb because there was a temporary problem with the archive
mirror. But eventually juju-mongodb3.2 was found and juju started trying
to use that instead of the old mongo 2.4, and that just breaks
everything because it tries to launch the new mongo on the old database.

## QA steps

The actual underlying bug meant having an archive mirror that *has* juju-mongodb but *doesn't* have juju-mongodb3.2. I'm not sure we need to go to that level to test this. But ideally we would just fail to install and people can go fix their mirror, rather than succeeding but with a version that will break us in the future.

## Documentation changes

None.

## Bug reference

[lp:1743901](https://bugs.launchpad.net/juju/+bug/1743901)

2.2 into 2.3

## Description of change

Just bringing the 2.2 branch into 2.3.
This brings in the fix for bug #1743901. And ignores the backported CI tests (assuming those have already been brought into 2.3 independently).

## QA steps

None.

## Documentation changes

None.

## Bug reference

See original PRs.

This allows updating or unsetting a subset of controller config values
in state. At the moment this is limited to audit log settings - once the
work has been done to determine how other values are used this can be
broadened to more of them.

Removing a value results in the default value being used.

This required adding v5 of the Controller API.

Moved cmd/juju/controller/getconfig.go to configcommand.go

When storing config that has been validated with the schema library, any
values that are in the schema as List(x) will end up being stored as
[]interface{}. Those values aren't comparable, so the `old == new` check
in settingsUpdateOps would panic. Use reflect.DeepEqual instead.

There is a new test to ensure that a nil pointer for current space names is preserved when one is passed in and there are no implicit constraints.

Cleaned up test semantics.

…API.

…-1746265

…ation.

To force the issue, you can add this patch:
diff --git a/worker/periodicworker.go b/worker/periodicworker.go
index 27d0f94..c560bbc 100644
--- a/worker/periodicworker.go
+++ b/worker/periodicworker.go
@@ -108,6 +108,8 @@ func (w *periodicWorker) run(call PeriodicWorkerCall, period time.Duration) erro
                                return err
                        }
                }
+               // XXX: Force race conditions to become apparent, do *not* leave this in code
+               time.Sleep(time.Millisecond)
                timer.Reset(nextPeriod(period, w.jitter))
        }
 }

And see that the old test would fail, while the new test still passes.

The synchronization points are now:

a) We know that call() has been triggered 2 times because we waited for it.
b) We know that call() won't be called again because we've called Kill().
c) We know that all nextPeriod have been called because we Wait() for the
   Worker to notice the Kill() and exit, which means it has gone around its
   loop and called next period and gotten all the way around to <-stop.

I also confirmed that moving the w.Kill() after the last select properly fails
the test because it gets the wrong number of nextPeriods (it gets an extra one
late, and fails to record both of the earlier ones.)

…ttent-test-1745332

simply because the agent pinger isn't alive on the server yet.

Conflicts:
	scripts/win-installer/setup.iss
	snap/snapcraft.yaml
	state/upgrades_test.go
	version/version.go

Most conflicts are just do to the version bump to 2.3.4 (since 2.3.3 was
released.)
One small conflict about both branches adding a new upgrade test.

…oller config, these are applied as constraints to the bootstrap and enable-ha commands.

There is a new test to ensure that a nil pointer for current space names is preserved when one is passed in and there are no implicit constraints.

Cleaned up test semantics.

…API.