Upgrading a sidecar charm with one workload container to one with no workload containers results in workload container still defined

This should get fixed in the 2.9 series. We did implement support for upgrading from a pod spec charm to a sidecar charm, it seems we need to look at how our sidecar charms themselves upgrade when the topology changes, and ensure that new versions of the charm get the new topology.

This is likely fixed now. Please re-open if still an issue.

I've just tested this on 2.9.42 and it still leaves me with a pod with two containers:
```
juju deploy nginx-ingress-integrator --channel=edge --revision=29 --resource placeholder-image='google/pause'
# Look at microk8s containers, two found
juju refresh nginx-ingress-integrator
# Look at microk8s containers, still 2, should be 1
```

This issue is due to how Juju patches the StatefulSet. I'm exploring options that we can maintain the ability for other entities (such as charms) to alter the StatefulSet and for those changes, where possible to persist. But it may be that we must overwrite the StatefulSet, which will require entities that wish to mutate the StatefulSet, to reapply their changes, which is not ideal.

We've just been bitten by this again as part of an indico upgrade on staging. Revision 126 of the charm specifies some resources that no longer exist in revision 133. If you try to deploy revision 126 now it will completely fail with something like https://paste.ubuntu.com/p/t7PjNqmgJX/.

In our staging deployment the charm upgrade is unable to happen because the statefulset defining containers that no longer exist and juju is trying to pull secrets for those images and the secrets no longer exist. We therefore have one pod stuck in "Terminating" status. Killing the pod doesn't help, it just respawns and we see the same `failed to introduce pod indico-1: already exists...` message in the logs for the charm-init container.

We're not sure if we can just edit the statefulset manually to allow the deployment to proceed.

I ran a test and confirmed that editing the statefulset pod template to remove the (I think 6) prometheus containers that are no longer in the new charm, plus the relevant (prometheus container) image pull secrets seems to do the trick.

My steps were to deploy stable on focal (rev 126) and then upgrade to edge (rev 134). juju status plus logs contained various errors, eg status showed

Unit Workload Agent Address Ports Message
indico/0* error idle 10.1.78.112 crash loop backoff: back-off 5m0s restarting failed container=indico pod=indico-0_m(fc8e8b2c-a1e9-4409-a7c7-589dd7fe9...

Editing the statefulset as above

Unit Workload Agent Address Ports Message
indico/0* waiting idle 10.1.78.89 Waiting for redis-broker availability