Remove DNS dependencies from deployment operations where possible

[nephomaniac]

This is only in the context of 'deploying' a cloud, and not 'supported architectures of a cloud'.

Currently there are places in the CB where DNS is assumed to be in place and working. In most places, these appear to be unnecessary as the information is already known/presented in the provided environment document. These may add:

• unnecessary ordering/timing constraints
• create an unnecessary need to validate/check DNS state for operations which do not require it.
• intermittent name resolution errors, and the need for even more code run in more places to handle these errors (retries, logging, etc).

Suggesting that we:

• Use IPs (where possible) for administrative operations during the deployment of a cloud. (Users/Applications outside of this context should use whatever means is supported/desired by the administrator.)
• Move the DNS portion to it's own recipe(s) so DNS setup can be run independently later if desired, and that operation is a bit more obvious to the end user as to what it is trying to achieve?
• If DNS configuration fails, that recipe should report and handle the failures, rather than inferring DNS is not working because it fails in some other random part of the cookbook.
• Allow for more async work in a deployment. If external env work is needed, a "mostly working" cloud can be deployed and this recipe can be run later with the appropriate attributes.

Extras:

• The DNS recipe could perform some minimal checks to validate DNS is in a working state? (currently it's "assumed" to be in a working state by the recipes which use it).
• If needed 'debug' operations for DNS can be added to the Calyptos project to help validate and setup external dependencies that dont make sense to add in this CB.
• Investigate what attributes are needed to configure and validate the DNS deps external to the cloud.
• Investigate adding a 'test dns server' recipe and attributes.

[nephomaniac]

esi-install-image should perform the following to work with potential dns issues commonly seen during installations:

1. check/qualify the availability of the cloud dns domain attribute
2. if dns attribute is qualified, check the s3 endpoint(url) with a simple request
3. if the s3 url is not available using the dns domain, fall back to IP+ service path and repeat the endpoint check.
4. If the endpoint checks fail, an informative error should be logged/thrown here, else the esi-install image command should be executed.