[BUG] DNS issue where deprovisioning sets the hostname to localhost.localdomain

**Describe the bug: A clear and concise description of what the bug is.**

Deprovisioning sets the hostname to `localhost.localdomain` but it also sets the hostname for `dhclient` to `localhost.localdomain`. This can result in `nslookup localhost` on the network resolving to another Virtual Machine in the starting state between the time where `dhclient` is initially run and when the hostname is setup by walinuxagent.

**Distro and WALinuxAgent details (please complete the following information):**
- Distro and Version: [e.g. Ubuntu 16.04]
- WALinuxAgent version [e.g. 2.2.40, you can copy the output of `waagent --version`, more info [here](https://github.com/Azure/WALinuxAgent/wiki/FAQ#what-does-goal-state-agent-mean-in-waagent---version-output) ]

CentOS 7.9 and Ubuntu. Although this will effect all distros if dhclient is run before the actual hostname is set.

**Additional context**

This breaks scripting that would rely on `localhost` being correct.

You can reproduce this with the following steps:
* Create a new image after running `waagent -deprovision`.
* On another VM on the VNET, run the command `watch nslookup localhost` (or run in a loop and pipe to a file)
* Start a new VM on the VNET with the image that was created
* For a short period while the new VM starts up you will see `nslookup localhost` being resolved to the new VMs private IP address

**Log file attached**

Any /var/log/messages will show the hostname being set to `localhost.localdomain` when the VM initially starts if it has been created after using waagent deprovision.