Support channel aliases tracking

[Stéphane Graber]

The channel aliases mostly behave like standard channels and can be used as such.
However they have an extra flag set "alias" which is set to the channel they're based on.

That same flag is passed as channel_target in channel.ini. If the client notices that its local value (channel_target) doesn't match the server's value (alias), then it should consider its internal version number to be 0 and do a full update to whatever is the latest version available in the channel.

This logic is to allow version downgrades when changing the alias to point to a different series.

This will need to be implemented and supported by the time we release 13.10 as we'll need this to flip daily to 14.04 when it opens.

[Stéphane Graber (stgraber)]

Server side code added to bzr will be used when I land the rewritten importer code, probably on Monday.

[Barry Warsaw (barry)]

The one question I have is this use case: let's say the channel alias has changed, but the user gives a specific build number via the cli, e.g. --build 47. Should we respect the '47' or clobber it with build 0? For now the easiest thing to do is to clobber it. I can see how to implement respecting the explicit command line option, but I suspect this isn't a use case we'll care about much, so I'm not going to implement that. Just something to keep in mind if it ever crops up.

[Barry Warsaw (barry)]

In the original description it says: "If the client notices that its local value (channel_target) doesn't match the server's value (alias), then it should consider its internal version number to be 0 and do a full update to whatever is the latest version available in the channel."

I don't think the second half of this (i.e. "do a full update") should be interpreted as equivalent to `system-image-cli -f full` since this might not leave us at the highest version number for that channel. E.g. if an upgrade path goes from 0:200:201:304 because 200 is a full update and 201 and 304 are deltas, then adding -f full would leave you at build 200 since it would ignore all deltas on the path.

So I think the actual interpretation of this feature is this: if the channel the device is tracking has an alias, and its channel.ini file has channel_target key, and the alias != channel_target, set the build number to 0 before calculating the upgrade path. Note of course that we do *not* use the channel_target or alias in any other way. Specifically, we still track the actually channel name from the channel.ini file.

For example, let's say 'daily' is aliased to 'saucy' and we're at build 300. Further, let's say a normal update would upgrade us through the path 300:301:304 with the latter two being deltas. But now 'daily' gets aliased to 'tubular' (because the Tubular Tapir series was opened). The channels.json 'daily' channel would now have an alias of 'tubular', but the channel.ini file would still have a channel_target of 'saucy'. We clobber the build number to 0 and calculate the upgrade path along the 'daily' channel (since now we don't care what its alias is). This leads to an upgrade path of 0:200:201:304.

Considering message #2 above, I've gone back and thought that explicitly providing a --build flag should override it. I'll see if I can make that work, but it's not the highest priority.