#13220

Merge 2.9

#13211 Fix data race (accessing charmInfo) in TestV2CharmExitsApplicationWorker
#13212 Fix retry-provisioning command
#13210 Add note and todo
#13209 Improve readablity of 'no prdesc not found' error message
#13214 Adds remaining authorization objects to ignore
#13215 Use a key-based mutex lock to download resources/agent bins once
#13218 Show application data set by the remote app in show-unit output
#13219 Add impish to the ubuntu series list

Trivial conflicts in imports/code comments.

```
Conflicts:
# apiserver/facades/client/client/client.go
# apiserver/facades/schema.json
# resource/resourceadapters/opener.go
```
## QA steps

See PRs

#13650

This follows on from the work done in #13215 which throttled resource downloads from the store.
Here we introduce limits to resource downloads from the controller to the workload nodes (initiated by the unit agents calling `resource-get`).

There are 2 new controller config attributes:
- controller-resource-download-limit
- application-resource-download-limit

The first limits the number of total downloads for any app hosted in a model on the controller.
The latter limits the number of downloads per application per model.
The default values for these limits are 0, meaning no throttling; the new behaviour is opt in.

## QA steps

I deployed the `dummy-resource` charm with slightly modified hooks; the line
`status-set maintenance $(cat $RES_PATH)`
was commented out.

First create a number of machines to run the charm
juju bootstrap 
juju controller-config controller-resource-download-limit=5
juju add-machine -n 20

Optionally turn on debug logging for `juju.resource.resourceadapters`
juju model-config logging-config="juju.resource.resourceadapters=DEBUG"

Let the machines start.
watch -c juju status --color

Then deploy the charm twice with different app name, using a large zip file
juju deploy /path/to/dummy-resource -n 10 --resource dummy=./dummy-resource.zip --to 1,2,3,4,5,6,7,8,9,10
juju deploy /path/to/dummy-resource -n 10 app2 --resource dummy=./dummy-resource.zip --to 11,12,13,14,15,16,17,18,19,20

status will show the message for each unit change to indicate the resource is delivered. Typically a few change at once.
debug-log will show the resource download lock being acquired in batches.

ssh into the machines and check the zip file is present in the unit resources directory.

## Bug reference

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