Handle lock addition as lock acquisitions
Handle lock addition as lock acquisitions

From stable-2.12 onwards no longer are explicitly added; they just
exist for all conceivable names/uuids. Nevertheless, addition was
handled special based on the assumption that no one else can have
a lock on an entity that is just being created.

This assumption, however, is wrong for instance names. Consider
the situation that an instance is first destroyed an then an instance
with the same name is created. While is instance is being destroyed,
there is the situation where the instance is still in the configuration
and the destroy job holds a lock on the instance. In that time, another
job, like group_verify_disks, can read the list of instances, decide
to wait for a lock on all the then existing instances, and eventually
get the locks, including the one on the instance just removed. And
while that job still has the (useless) lock, the new creation job can
come to the lock-addition stage.

To live with the presence of those races, just wait for newly added
locks as for any other locks. Any job with a lock on a no longer existing
entity will release it pretty soon anyway.

Signed-off-by: Klaus Aehlig <4ce51de36d9068cd7db2eec1151e0f3f95419008@google.com>
Reviewed-by: Petr Pudlak <9d19625f8ee825a2c398462ed335cbcf98f79c32@google.com>

yiannist/ganeti,ganeti-github-testing/ganeti-test-1,apyrgio/ganeti,yiannist/ganeti,leshchevds/ganeti,dimara/ganeti,leshchevds/ganeti,ganeti-github-testing/ganeti-test-1,mbakke/ganeti,andir/ganeti,ganeti/ganeti,mbakke/ganeti,leshchevds/ganeti,apyrgio/ganeti,onponomarev/ganeti,andir/ganeti,ganeti/ganeti,dimara/ganeti,bitemyapp/ganeti,ganeti/ganeti,mbakke/ganeti,yiannist/ganeti,grnet/snf-ganeti,andir/ganeti,bitemyapp/ganeti,onponomarev/ganeti,grnet/snf-ganeti