Bug 1729746

Description of problem:
Creating a subnet requires multiple transactions:
  - 1 for updating the network object
  - 1 for creating the dhcp options object
  - 1 for updating the dhcp object options
  - 1 per each existent logical network port existent in the network

Since it is not done via a transaction (a mechanism that is now available on the provider code base), failing to create a subnet can leave leftovers behind (e.g. when it fails for one of the ports; the logical switch object is updated, the dhcp option object is created, the dhcp object is updated, and X ports are updated).

Using the transaction mechanism is a lot safer, since it assures either everything goes according to plan, or nothing does, enabling the system to be more scalable / deterministic.  

Version-Release number of selected component (if applicable):
1.2.22

How reproducible:
always

Steps to Reproduce:
1. create a logical switch
2. create some 10 ports on that logical switch (the more the easier it is to reproduce)
3. create a subnet on top of the network object
4. interrupt the REST client before receiving a response from the provider

Actual results:
Some of the ports will not have been updated - missing IP addresses

Expected results:
Either all ports are updated (create subnet succeeded), or none are (create subnet failed).