Reserve 5 migrations for backports

Reserve 5 migrations incase the need arises to backport any
fixes that require a db migration in stable/juno.

We've never set this up in the past and we did run into a case
last cycle where we had to hack some things around to make it work
without the place holder.

Why 5?  Why not?  For as little as we touch the DB historically
this number should be more than sufficient.

Change-Id: I2830f6557c65c4c9b3056bb5ee72b17346e21823
Add ability to update migration info on backend

The current migration process creates a new volume,
xfr's it's contents, then deletes the original and
modifies the new volume to have the previous ID.

All in all this is kinda troublesome, but regardless
the bigger problem is that the generic impl doesn't
provide any method to tell the backend devices that
their device names/id's have changed.

This patch provides a method to inform backends
that a migration operation has been completed on
their target volume.

It shouldn't be necessary to do anything with the originating
or source volume because it's deleted as part of the process.

Change-Id: Ib5e6a47fe9eedab3e60e77a6c2d987355c0bf167
Closes-Bug: #1383499
Merge "Add ability to update migration info on backend"
Merge "Reserve 5 migrations for backports"