Enable charmcraft builds for all types of charmsm (charmhub migration)

[ajkavanagh]

The consequence of the charmhub migration is that all charms have a charmcraft.yaml. In order to troubleshoot/head-off issues related to charmcraft builds, the CI needs to also do a charmcraft build.

Note: in the longer time, we actually want launchpad to build the charm in a branch, but that'll be dependent on syncing the git repo (more frequently), target a PR (rather than a git branch), etc. So, no really a short term solution.

But in the meantime, doing the charmcraft build in the CI (for amd64) will result in a <name>...charm file which doesn't have access to the tox.ini in the src/ directory (for reactive charms). Thus a workaround is done to put a func-target tox target in the top level reactive charm, and then use that to call the src/tox.ini func-target target.

The point of this bug report, is that we need to overhaul how and where the tox.ini is for charmcraft.yaml charms is, so that going forward we can simplify the logic in zosci-config.

[wolsen]

The consequence of the charmhub migration is that all charms have a charmcraft.yaml. In order to troubleshoot/head-off issues related to charmcraft builds, the CI needs to also do a charmcraft build.

Note: in the longer time, we actually want launchpad to build the charm in a branch, but that'll be dependent on syncing the git repo (more frequently), target a PR (rather than a git branch), etc. So, no really a short term solution.

Just as a comment for future consideration, this might need further exploration as to the feasibility of doing this as there's a lot of complexity and I'm struggling to find the benefit since the resultant charm is published via the charm-build job and could be deployed/side-loaded separately. I think the near to medium term scenario our current approach of building the charm using charmcraft gets us close enough.