Comment 7 for bug 2031375

The intended behaviour of the system is that a client that is already tracking a channel gets whatever was most recently in that channel, even if that channel is closed. A client that tries to install from or switch to that channel gets an error.

This is controlled by two fields in the Store refresh API's request body: context's tracking-channel specifies the old channel, and action's channel specifies the new one. The API correctly returns the most recent revision when snapd sends tracking-channel=stable, but erroneously returns an error when tracking-channel=latest/stable. I'm fixing that inconsistency, so both will return the most recent revision, matching the existing behaviour for channel=stable.

Now, this doesn't fix the originally reported issue. I don't actually know what the right behaviour is -- for dangerously sideloaded snaps I think we require an explicit `snap refresh --amend` to allow any upgrade at all, but I guess for asserted sideloads we don't do that. It doesn't seem like snapd should allow a channelless `snap refresh` for a sideloaded snap if it doesn't already have a known channel. And we should probably adjust the Store's refresh API to allow omitting tracking-channel, so refreshing onto a channel from no channel gets the same "can't refresh onto a closed channel" behaviour.