Juju deploy bundle parses local charms incorrectly

[Kenneth Koski]

I have a bundle that looks like this:

```
---
bundle: kubernetes
applications:
  foo:
    charm: /built/foo_ubuntu-20.04-amd64.charm
    scale: 1
```

I try to deploy it with `juju deploy ./test-bundle.yaml`, and it fails with this message:

```
Executing changes:
- upload charm istio-pilot from local for series focal with architecture=amd64
ERROR cannot deploy bundle: cannot deploy local charm at "/built/foo": file does not exist
```

What's interesting is that if I change the bundle to point at a non-existent file, deploying it will fail with this message:

```
charm path in application "foo" does not exist: /built/bad-path.charm
```

It looks like Juju is reading the built charm to parse out `name:` from `metadata.yaml`, then going back and trying to use that as a filename to read from. This won't exist, even with `.charm` appended to it, as charmcraft has started inserting the base name and architecture into the built charm filenames.

[Kenneth Koski (knkski)]

It looks like it has something to do with the charm already being deployed. I have a bundle that looks like this, where `foo.charm` is a packed `istio-gateway` charm:

```yaml
---
bundle: kubernetes
applications:
  asdf:
    charm: ./foo.charm
    scale: 1
```
```
# Works great once
$ juju deploy ./test-bundle.yaml
Executing changes:
- upload charm /built/foo.charm for series focal with architecture=amd64
- deploy application asdf with 1 unit on focal
  added resource noop
Deploy of bundle completed.
```

```
# Breaks the second time
$ juju deploy ./test-bundle.yaml
Executing changes:
- upload charm istio-gateway from local for series focal with architecture=amd64
ERROR cannot deploy bundle: cannot deploy local charm at "/built/istio-gateway": file does not exist
```

[Kenneth Koski (knkski)]

@jameinel informed me that the general goal is to eliminate absolute local paths for charms in bundles, as well as limit relative paths to being a subdirectory of wherever bundle.yaml lives. He also pointed me towards bundle zips, which are simple zip files with a bundle.yaml at the root level, as well as any relevant charm artifacts.

Zipping everything up into a bundle works in general, but exhibits the same behavior as this bug. I have a bundle.yaml that references the included charms as e.g. `./istio-gateway_ubuntu-20.04-amd64.charm`, and get this error when deploying it:

$ juju deploy ./bundle.zip
Executing changes:
- upload charm istio-gateway from local for series focal with architecture=amd64
ERROR cannot deploy bundle: cannot deploy local charm at "istio-gateway": file does not exist

[Simon Richardson (simonrichardson)]

This ends up being more convoluted than we'd want. Setting the path of the charm to be the name of the charm URL isn't ideal, as we weaken what the name of the charm URL stands for. It is no longer a name, but a locator and we could change the charm URL to take that into consideration, along with validate locator vs name.

If we did then change the name to locator, the problem then requires a series of upgrade steps. Except you can't upgrade a charm URL of an existing deployed application. As the charm URL is used as an opaque foreign key to link documents in collections, in addition to waking up watchers causes Juju to lock up during an upgrade step migration and there is no way to undo that. Juju is essentially borked(see an example of attempting to do this[1]).

Additional issues of export-bundle and cross model migrations might also have some potential warts that haven't also been bottomed out.

I believe this will be solved when doing the data changes when removing mongo.

1. https://github.com/juju/juju/pull/12846

[Simon Richardson (simonrichardson)]

So double deploying of local charms is fixed, my main concern with the change is that we can't deploy from bundle-export. We'll need to fix that in the future. For now, this was fixed in https://github.com/juju/juju/pull/13576