Better interface handling for Vultr, expect unexpected DHCP servers

[eb3095]

Proposed Commit Message

Better interface handling for Vultr, expect unexpected DHCP servers

If a private interface is configured, has a DHCP server on it, and Cloud-Init runs, the Datasource fails to fail over to the next interface interrupting seeking. Configuring it as such can also lead to delays in deploy time if it did. This sorts the interface list to limit the potential of this occurring. Checks for the metadata route before trying, and now appropriately fails over if those contingencies fails by appropriately continuing to seek on metadata failure as was originally intended. Ideally the upcoming candidate_nic would of been used here to avoid the interface list function.

Additional Context

The complexity here is due to the wild inconsistency on the platform. An image may end up on a vm, or a baremetal server, or not even be made by us. Options to handle this has been limited. New unittests were added to keep this in check as well.

Test Steps

Deploy a server with a private interface with a dhcp server running on the private network.

Checklist:

• [ X ] My code follows the process laid out in the documentation
• [ X ] I have updated or added any unit tests accordingly
• [ X ] I have updated or added any documentation accordingly

[TheRealFalcon]

Looks good with an inline question and nit.