Make rpc upgrade_levels automatically discoverable

Today when someone wants do a rolling upgrade of nova-compute they have to:

1) Upgrade everything except nova-compute.
2) While upgrading, set the rpc version cap config option in nova.conf (upgrade_levels.compute) to the version of nova-compute being used.
3) Roll out the new nova-computes.
4) Remove the rpc version cap under upgrade_levels.compute.

A deployer shouldn't have to deal with setting rpc version caps via config files every time they want to upgrade, this process should be taken care of by nova itself. Nova should be able to discover what message versions a specific service supports.

With this blueprint the same upgrade should look like:

1) Upgrade everything except nova-compute. the new services automatically detect that a rpc version cap is needed to talk to the nova-computes.
3) Roll out the new nova-computes. rpc version cap is automatically dropped.

There are several possible ways to implement this including adding a rpc_version column to the services table.

Since we already have a working solution for rolling upgrades, this blueprint is not a requirement for rolling upgrades, but rather a nice to have.

This blueprint was drafted with the goal of targeting Juno.