This MP retrieves the resources from snap refresh and downloads its
blob, resource revision assertion and resource pair assertions. It
also does a bit of refactoring of the current logic, so that the newly
added logic does not impact the readibility.
Currently snap tracks are resolved to latest by default. Since we
support setting custom default tracks, this may cause unexpected
behavior when the user doesn't provide the track during export.
To solve the issue, we use the `default-track` field from the snap
info API.
Refactor snap export to use refresh API for revisions.
The export snap process used info API to retrieve all the channel
maps. The info API does not support resolving by revision. The logic
is updated so that all the revisions and channel maps and retrieved
only from refresh API. Since info will be used for default track
resolving, snap metadata is still read from there (and to make
refresh calls lighter).
Fetch channel-specific actions-, bundle-, config-, and metadata-yamls
These -yaml fields are parsed from the .yaml files included in the charm or bundle. It matters that the
content we return match the content of the actual file in the resolved revision: Juju is sensitive to this,
e.g. it will throw an error if the config-yaml metadata field returned from /refresh does not match the
config.yaml file in the charm binary.
Currently, we extract these fields from the `default-release` item from the /info response, because
/refresh does not give us actions- and bundle-yaml. /info has rudimentary revision resolution to compute
the default release, and accepts the `channel` param as input to do this. We're currently not using the
param, so `default-release` is always from the default track's most stable channel, which might not be
what the user wants.
Thus, this commit calls /info with the `channel` param, as given by the user. We then call /info again
without the param to identify the default track. As such the commit also contains some refactoring of
the default track-related functions.
