Most of the time they're constant, ens5 primary and ens6 hotplugged, but
this is not always the case. This was causing occassional failures. Fix
this by using ip to figure out which interfaces we should use instead of
hard coding them

…ability_of_spaces_ec2_2.9

juju#15487

Most of the time they're constant, ens5 primary and ens6 hotplugged, but this is not always the case. This was causing occasional failures. Fix this by using ip to figure out which interfaces we should use instead of hard coding them

## Checklist

- [x] Code style: imports ordered, good names, simple structure, etc
- [x] Comments saying why design decisions were made
- ~[ ] Go unit tests, with comments saying what you're testing~
- [x] [Integration tests](https://github.com/juju/juju/tree/develop/tests), with comments saying what you're testing
- ~[ ] [doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages~

## QA steps

```sh
./main.sh -v -c aws -R eu-west-2 spaces_ec2 test_upgrade_charm_with_bind
./main.sh -v -c aws -R eu-west-2 spaces_ec2 test_juju_bind
```

Should both pass

Add juju- to aks test resource group name for easy cleanup.

Improve convertCharmOrigin to deduce a platform where the origin is not
available. This can happen when deploying or refreshing charms with an
old juju client unaware of an origin.

juju#15492

The interactive add-cloud is painful because it will often reject the endpoint URL without giving any reason why. See https://bugs.launchpad.net/juju/+bug/1908630
```
Enter the API endpoint url for the cloud []: 172.31.47.119
Can't validate endpoint: No Openstack server running at 172.31.47.119

Enter the API endpoint url for the cloud []: http://172.31.47.119/
Can't validate endpoint: No Openstack server running at http://172.31.47.119/

Enter the API endpoint url for the cloud []: http://172.31.47.119/identity/v3
Can't validate endpoint: No Openstack server running at http://172.31.47.119/identity/v3

Enter the API endpoint url for the cloud []: 172.31.47.119/identity
Can't validate endpoint: No Openstack server running at 172.31.47.119/identity

Enter the API endpoint url for the cloud []: http://172.31.47.119/identity
Can't validate endpoint: No Openstack server running at http://172.31.47.119/identity
```

In the Openstack provider's `Ping` method, at least pass on the error information to the user, to make it a little less painful.
```
Enter the API endpoint url for the cloud []: 172.31.47.119
Can't validate endpoint: No Openstack server running at 172.31.47.119: auth options fetching failed
caused by: request available auth options: failed executing the request /
caused by: Get "/": unsupported protocol scheme ""

Enter the API endpoint url for the cloud []: http://172.31.47.119
Can't validate endpoint: No Openstack server running at http://172.31.47.119: auth options fetching failed
caused by: request available auth options: failed executing the request http://172.31.47.119/
caused by: Get "http://172.31.47.119/": dial tcp 172.31.47.119:80: connect: no route to host
```

Do the same with the MAAS and LXD providers.

Also, fix a silly check in the LXD provider's `Ping` method that was rejecting perfectly good URLs. We're already using `lxd.EnsureHostPort(endpoint)` to fill in the scheme/port if not provided, but we were checking the returned value equals the input (and returning an unhelpful error if not). Remove this check.

## Checklist

*If an item is not applicable, use `~strikethrough~`.*

- [x] Code style: imports ordered, good names, simple structure, etc
- ~[ ] Comments saying why design decisions were made~
- [x] Go unit tests, with comments saying what you're testing
- ~[ ] [Integration tests](https://github.com/juju/juju/tree/develop/tests), with comments saying what you're testing~
- ~[ ] [doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages~

## QA steps

Run `juju add-cloud` interactively, and provide a bogus URL.

When dealing with invalid yaml in local bundle, the error was treated as
if the file was not present, therefore continuing to treat the input as
a charm bundle url. This fix returns the error if it's a NotValid error.

In future versions more firewall related tests will be added

…e_ec2_to_firewall

juju#15499

In future versions more firewall related tests have be added

Change the name here to keep the suite names consistent

## Checklist

- ~[ ] Code style: imports ordered, good names, simple structure, etc~
- ~[ ] Comments saying why design decisions were made~
- ~[ ] Go unit tests, with comments saying what you're testing~
- [x] [Integration tests](https://github.com/juju/juju/tree/develop/tests), with comments saying what you're testing
- ~[ ] [doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages~

## QA steps

```sh
./main.sh -v -c aws -p ec2 firewall
```

Split out into its 2 functions, handling existing origins and creating
a new origin for special cases. Much easier to read.

Test SetCharm from v12, which is used with clients older than 2.9 and cannot contain
an origin or base.

juju#15497

When dealing with invalid yaml in local bundle, the error was treated as if the file was not present, therefore continuing to treat the input as a charm bundle url. 

This patch fixes the returned error if it's a NotValid error.

## Checklist

- [X] Code style: imports ordered, good names, simple structure, etc
- [X] Comments saying why design decisions were made
- [X] Go unit tests, with comments saying what you're testing
- [ ] ~[Integration tests](https://github.com/juju/juju/tree/develop/tests), with comments saying what you're testing~
- [ ] ~[doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages~

## QA steps

Having an empty juju model and this test.yaml bundle:
```yaml
series: focal
applications:
 ubuntu:
 charm: ubuntu
 channel: stable
 revision: 21
 num_units: 1
 to:
 - "0"
 constraints: arch=amd64
va
machines:
 "0":
 constraints: arch=amd64
```
then you should get this error:
```sh
$ juju diff-bundle test.yaml
ERROR cannot unmarshal bundle contents: unmarshal document 0: yaml: line 12: could not find expected ':'
```
if you remove line 12 then:
```sh
$ juju diff-bundle test.yaml
applications:
 ubuntu:
 missing: model
machines:
 "0":
 missing: model
```
## Bug reference

https://bugs.launchpad.net/juju/+bug/2015315

Assert the DocID hasn't been created. The DocID is based on the offer name
not the application name.

Group refcount doc creation by application name as there may be more
than on offer per application. Use new method newnewApplicationOffersRefOp
to allow for specifying the count used.

…igration-txn-fail

juju#15508

There were 2 things preventing model migration when more than one cmr offers for an application. 

One was the docID asserting a doc wasn't there, did always match the docID of what was being inserted. A mismatch between offerName and appName.

The second was having 2 refcount docs with a count of 1 based on appName instead of 1 refcount doc with a count of 2 where there were 2 offers on the same application. At first glance, incApplicationOffersRefOp should have returned a doc with a count of 2, however all cmr offer data was run as a single txn rather than multiple, thus the doc couldn't be found to be changed.

## Checklist

- [x] Code style: imports ordered, good names, simple structure, etc
- [x] Comments saying why design decisions were made
- [x] Go unit tests, with comments saying what you're testing
- ~[ ] [Integration tests](https://github.com/juju/juju/tree/develop/tests), with comments saying what you're testing~
- ~[ ] [doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages~

## QA steps


```sh
$ juju bootstrap localhost dst
$ juju bootstrap localhost src
$ juju add-model moveme
$ juju deploy mongodb --channel candidate 
$ juju offer mongodb:database 
$ juju offer mongodb:database mongdo-database
$ juju migrate moveme dst
```


## Bug reference

https://bugs.launchpad.net/juju/+bug/2016333

…ails-refresh

[JUJU-3518] fix lp 1999640 local charm fails refresh

juju#15506

Merges:
- juju#15487
- juju#15490
- juju#15492
- juju#15499
- juju#15497

Conflicts solved trivially:
- provider/maas/environprovider.go
- tests/suites/spaces_ec2/util.sh

- Specifically testing fix for macos

juju#15510

Updates the mgo lib in 3.1 onwards. This to bring in the latest change that deals with some macos testing issues.

## Checklist

- [x] Code style: imports ordered, good names, simple structure, etc
- [x] Comments saying why design decisions were made
- [x] Go unit tests, with comments saying what you're testing
- [x] [Integration tests](https://github.com/juju/juju/tree/develop/tests), with comments saying what you're testing
- [x] [doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages

## QA steps

Run juju tests

## Documentation changes

N/A

## Bug reference

N/A

juju#15518

Merge branch '2.9' into 3.0

```
# Conflicts:
# apiserver/facades/client/application/application.go
# apiserver/facades/client/application/application_unit_test.go
```

juju#15520

Merge remote-tracking branch 'upstream/3.0' into 3.1:

```
# Conflicts:
# apiserver/facades/client/application/application.go
# apiserver/facades/client/application/application_unit_test.go
# cmd/juju/application/diffbundle.go
```