Make allocate network more reliable.

In a contended host this method fails because it uses the default timeout
(typically one minute). The error condition can be reproduced quite reliably
using the grinder launch_multiple test. With this commit you get the following
in the logs (folsom):

2013-06-04 23:49:41 17245 DEBUG nova.openstack.common.rpc.amqp [-] MSG_ID is 09d2220e2296439ebb6d41488ac8a786 multicall /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py:355
2013-06-04 23:49:42 17245 ERROR nova.openstack.common.rpc.common [-] Timed out waiting for RPC response: timed out
2013-06-04 23:49:42 17245 TRACE nova.openstack.common.rpc.common Traceback (most recent call last):
2013-06-04 23:49:42 17245 TRACE nova.openstack.common.rpc.common   File "/usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/impl_kombu.py", line 518, in ensure
....
2013-06-04 23:49:42 17245 TRACE nova.openstack.common.rpc.common timeout: timed out
2013-06-04 23:49:42 17245 TRACE nova.openstack.common.rpc.common
2013-06-04 23:49:42 DEBUG nova.gridcentric.manager [req-42327ad0-9853-4094-bd55-cc47809ec3c5 cd680f57d92e440b8827d25304dd9110 63575cec367a4703aec77fe504c74a80] Allocate network for instance=instance-0000ba3e timed out after 60 seconds, try 0. _instance_network_info /usr/lib/python2.7/dist-packages/gridcentric/nova/extension/manager.py:865

Which would have otherwise killed the launch.

This is in line with findings from Peter about lock convoy-ing with nova-network.

The proposed fix is to catch the timeout, and keep retrying getting the network
info we asked to allocate until we exhaust the time specified in our own
internal timeout. That puts the policy for this method in line with that used
for other network methods we call like pre_live_migration.

Change-Id: I76b3964f737cd703d7d34b16ed162f779e0be262