Enable mixer reset functionality

[reaganlo]

User should have an option to reset mixer to a desired version. Based on implicit behavior or through additional flags user should be able to do the following:

• Reset the mixer workspace to the previous successful mix version or to a specified mix version.
  E.g. sudo mixer reset or sudo mixer reset --to <ver>
  This should include resetting the latest version files and recreating the latest signature file. The content of rest of the mix versions should not be modified.
• User should have an option of deleting the content of all mix versions greater than the reset version.
  E.g. sudo mixer reset --clean
• User should have an option of not recreating the latest signature file.
  E.g. sudo mixer reset --no-signing

Note: Currently the following are the files related to mix versioning:

- mixversion
- mixer.state
- update/image/LAST_VER
- update/www/version/latest_version
- update/www/version/latest_version.sig
- update/www/version/format<format>/latest_version
- update/www/version/format<format>/latest_version.sig

[reaganlo]

@mbelluzzo I have listed the requirements based on our discussion. Can you please take a look at it and confirm.
@ashleshaAtrey @jwakre FYI

[mbelluzzo]

Should --to <ver> imply --clean?

I mean, is it possible to have a sane state of the update/ folder if one rollbacks 3 builds and than issue a new build without passing --clean? Even for rolling back just a single version.

Maybe another way to think about this is: do we have an use case where --clean would not be desired? If so, is that the default case? Or instead of --clean we actually should have --no-clean to deal with this corner case.

The --no-signing is needed and looks good!

[rchiossi]

Should --to <ver> imply --clean?

One of the planned uses for this feature is to crete "forks" on the stream, which mean being freely able to move back an forth through previous builds (e.g. go back 2 versions in case of a format bump).

I mean, is it possible to have a sane state of the update/ folder if one rollbacks 3 builds and than issue a new build without passing --clean? Even for rolling back just a single version.

It really depends on how this is implemented. Ideally, published content won't change during a reset (everything inside update/www) unless clean is specified, in which case rolling back to an arbitrary version is possible without a clean. Relevant published content like update/www/version/latest_version and its respective sig will be overwritten once a successful build in generated, so keeping them around shouldn't affect sanity.

Maybe another way to think about this is: do we have an use case where --clean would not be desired? If so, is that the default case? Or instead of --clean we actually should have --no-clean to deal with this corner case.

Also consider that clean can be fairly dangerous and can destroy a good update stream if misused. Keeping it explicit could minimize the risk.