Remove SELECT FOR UPDATE in ip allocation code

Instead of using a SELECT FOR UPDATE to ensure consistency
put in place an optimistic strategy according to the situation:
1) update the record only if the record contains expected values
or
2) deletes the record straight away and perform a check to
rollback the operation if it wasn't allowed.

IPAvailabilityRange keeps track of which address ranges are still
available for allocation. _try_generate_ip and _allocate_specific_ip
were locking this table to make sure that only one process could
modify the data in the table. With this patch a compare strategy
is in place. The IPAvailabilityRange is updated only if no other
process modified it. If a modification occurred the operation will
be retried after getting a fresh copy of the data from the DB.
IPAllocation is created right after the IP range update.

SELECT FOR UPDATE is removed from _rebuild_availability_ranges.
This function is called if there's no IPAvailabilityRange available
for a subnet or by _update_subnet_allocation_pools which removes
the IPAvailabilityRange associated with the subnet before calling
_rebuild_availability_ranges. In any case no IP can be generated
by another process for this subnet since there's no
IPAvailabilityRange record in the DB. Two processes could perform
_rebuild_availability_ranges at the same time, that's why a
DBDuplicateEntry is catched.

This change moves DB_MAX_ENTRIES to constants in order to make it
available for reference from this new code.

In _try_generate_ip IPAllocationFailure is raised instead of
IpAddressGenerationFailure to be consistent with the decorator
_retry_ip_allocation. _generate_ip is refactored accordingly

Closes-bug: #1331564
Closes-bug: #1332923
Closes-bug: #1313851

Co-Authored-By: Carl Baldwin <carl.baldwin@hp.com>

Change-Id: I7eeb687a8071c8f82cadbd51beb4668e371b2d4c