Support version upgrades in Krill clusters with shared data

[timbru]

If multiple Krill instances use the same shared data store (PostgreSQL), they should all run the same version of Krill - or bad things can and probably will happen.

The best way to prevent issues in this scenario would be to:

• stop all Krill instances
• make a backup of the data
• upgrade one node
• start it and let it do the migration
• then upgrade other nodes

However, we cannot be sure that operators will always do this.

So, it would be very useful to modify or extend the PropertiesManager to support the notion of not just the current Krill version, but also of any upgrades that may be in progress.

We can then use to do the following:

• prevent multiple concurrent upgrades
• let Krill monitor the current version and exit if it is behind the data (in case people forget to stop all nodes).
• let Krill refuse to start if it is behind
• possibly.. define behind in this context as a version difference that implies a breaking change (e.g. 0.14.0 -> 0.14.1 would be okay, but 0.14.0 -> 0.15.0 would not).