Stop accepting to update AZ names if instances are there already

Availability zones (AZs) are just an abstract API model that doesn't correspond to some real object on the Nova side. Rather, it's just a Facade for exposing to end-users the value of a specific aggregate metadata key and thus allow end-users to play with aggregates using certain rules.

The fact is that it's possible for an end-user to list all the availability zones and accordingly boot instances on some AZs.
Unfortunately, as an operator can modify any metadata, it is possible to change the value of the availability_zone key for a specific aggregate and accordingly change what the user can see when looking at AZs.
As a consequence, it's highly confusing. Say I'm Alice and I want to boot an instance on AZ foo, I do that.
Then, 2 weeks after, I want to start yet another server and I'm looking up at AZ foo but can't find it. Why ? Eh, wait? Why my existing server is in AZ 'bar' ?

See, there are a ton of implications when changing an AZ name. For example, yet another problem would be that Bob who is admin wanted to have all the instances be in a specific AZ by default, so he gently did set default_schedule_zone to "foo".
Unfortunately, Charlie wanted to rename "foo" into "bar". He did that, so kabooooom for all new instances which can't find "foo".

All of that is very error-prone and since we don't expose the aggregate UUID for knowing the real value of an AZ, the only unique identifier is the name. Yeah, terrible.

So, I'm proposing to provide a new microversion and return an invalid aggregate update action if existing instances are running (by modifying nova.compute.api._is_safe_to_update_az).