DHCP agent: log when reloading allocations for a new VM port

DHCP agent: log when reloading allocations for a new VM port

This will help us to see more clearly if failing DHCP for a new VM -
as seen in failures such as the following traceback from [1] - is
caused by DHCP configuration being too slow, as suggested by the
referenced bug.

Traceback (most recent call last):
  File "/home/aqua/tempest/tempest/test.py", line 125, in wrapper
    return f(self, *func_args, **func_kwargs)
  File "/home/aqua/tempest/tempest/scenario/test_server_basic_ops_38.py", line 105, in test_server_basicops
    self.verify_ssh()
  File "/home/aqua/tempest/tempest/scenario/test_server_basic_ops_38.py", line 95, in verify_ssh
    private_key=self.keypair['private_key'])
  File "/home/aqua/tempest/tempest/scenario/manager.py", line 310, in get_remote_client
    linux_client.validate_authentication()
  File "/home/aqua/tempest/tempest/common/utils/linux/remote_client.py", line 55, in validate_authentication
    self.ssh_client.test_connection_auth()
  File "/home/aqua/tempest/tempest/common/ssh.py", line 150, in test_connection_auth
    connection = self._get_ssh_connection()
  File "/home/aqua/tempest/tempest/common/ssh.py", line 87, in _get_ssh_connection
    password=self.password)
tempest.exceptions.SSHTimeout: Connection to the 172.17.205.21 via SSH timed out.
User: cirros, Password: None

[1] http://logs.openstack.org/39/194939/19/check/gate-grenade-dsvm-neutron/82a7e58/

Change-Id: I5d77762bf8d4caa2e6f8b3527a30bf80bac62085
Related-Bug: #1453350