Description of problem:
network addition verbs accept a network definition dictionary that allows to 
specify, among other things, the ip configuration and the booting protocol.

In case the booting protocol for the network is DHCP, an option was made
available called 'blockingdhcp' that is supposed to give the user the option
to wait for dhcp addressing before returning from the network configuring verb,
and the default was set to be non-blocking, i.e., asynchronous.

The problem lies that as part of the network refactorings, the default
regressed into being always blocking and the blockingdhcp option became a flag
for setting its opposite, i.e., for performing the dhcp addressing
asynchronously.

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


How reproducible: 100%


Steps to Reproduce:
1. vdsClient -s 0 addNetwork bridge=foo nics= bootproto=dhcp

Actual results:
Returns as successful even though the dhcp addressing cannot succeed (due to it
being a network consisting solely of an isolated bridge) because taking up the
network was performed asynchronously.

Expected results:
The network addition fails.

Additional info:
The steps above are the simplest way to reproduce, but the opposite is true,
if you rely on having the operation respect blockingdchp so that when it
returns successfully the device already has dhcp addressing, that will fail
as well.