Provide granular checkpoints for move_and_rebuild_hosts.py

[sadsfae]

This issue covers providing transparent look into the percentage of an environment's buildout/validation as well as to accomodate provisioning checks into situations where we add net-new systems to already-existing, running assignments.

This might manifest itself in two major ways

• make move_and_rebuild_hosts.py granular, capturing what's passed/failed across all the various actions as to not perform them again if they have already succeeded, or in case of power actions been executed
• store these values in a dict or other data structure, potentially utilizing the hosts collection in mongo as needed.
• provide a "ready" status percentage on the automated system assignments page based on what is left to be processed by quads-cli --move-hosts --dry-run and illustrate this in the wiki assignments page regeneration. addressed in 3485b88

This is particularly useful to cover validation gaps we have currently in systems that are added to already-running and validated/released environments

UPDATE: We are going to address this with: #256 instead here.

[sadsfae]

The following patchset provides the visible provisioning and move status indicators as a percentage on the assignments page:

https://review.gerrithub.io/c/redhat-performance/quads/+/463515

We still need to discuss, architect and implement the following:

1. simple, pragmatic way to provide coverage for checking host build status for systems moving into an already-existing cloud
2. ensure changes are complimentary to the inclusion of asyncio which we're aiming to adopt ASAP as soon as 1.1.0 is stable as outlined here:

#256
#266

Most likely this will involve just refactoring validate_env.py to move the build status checking into move_and_rebuild_hosts.py.

[sadsfae]

Closing this, the scope has changed to only provide visual progress status on assignments page, we will accomplish the granularity break-out here with a proper asyncio implementation as noted here:

#256

[sadsfae]

After some further discussion we're re-opening this as some elements can be implemented that compliment asyncio here:

https://review.gerrithub.io/c/redhat-performance/quads/+/463871

[sadsfae]

There are elements of this RFE that can/should be implemented post-asyncio, pushing this to 1.2 milestone.

[sadsfae]

This is related in part to serving the foundation for this 2.0 RFE: #471