In order to support a more complex syntax for root device hints (e.g
operators: greater than, less than, in, etc...) we need to stop relying
on the kernel command line for passing the root device hints. This patch
changes this approach by getting the root device hints from a cached
node object that was set in the hardware module.

Two new functions: "cache_node" and "get_cached_node" were added to the
hardware module. The idea is to facilitate the access to a node object
representation from the hardware extension methods without changing
method signatures, which would break compatibility with out-of-tree
hardware managers.

Note that the new "get_cached_node" is just a guard function to
facilitate the tests for the code.

The function parse_root_device_hints() and its tests were removed since
it's not used/needed anymore.

Partial-Bug: #1561137
Change-Id: I830fe7da1a59b46e348213b6f451c2ee55f6008c

If two hardware managers have the same clean step, for example
'erase_devices' in the GenericHardwareManager and a custom manager,
IPA must determine which step should be kept and which should be run
in order to prevent running the step multiple times.

This patch uses the following filtering logic to decide which step
"wins":
- Keep the step that belongs to HardwareManager with highest
  HardwareSupport (larger int) value.
- If equal support level, keep the step with the higher defined
  priority (larger int).
- If equal support level and priority, keep the step associated with
  the HardwareManager whose name comes earlier in the alphabet.

Other than individual step priority, picking which step to keep does
not actually impact the cleaning run. However, in order to make
testing easier, this change ensures deterministic, predictable
results.

Co-Authored-By: Mario Villaplana <mario.villaplana@gmail.com>
Co-Authored-By: Jay Faulkner <jay@jvf.cc>
Co-Authored-By: Brad Morgan <brad@morgabra.com>
Change-Id: Iaeea4200c38ee22cab72ba81c1dbae3389e675e4

If a clean step returns a tuple (like the output of
processutils.execute), WSME raises an error about the type. Casting
the result as a list seems to make it work. This is almost certainly
a bug in WSME, but after digging a bit I couldn't find one.

Change-Id: I91cb7a989ab56c0942469e03937945d4a590ad95
Partial-bug: #1493554

Adding documentation for methods in these files that were missing
docstrings.

Change-Id: I2ad9f85605720ab2295dec3d0436ff0af07847c2
Partial-bug: 1367915

This is a fixup patch for bde6ed557034bc2eac633ff84f2e9515a5ef14d6,
and should follow the OpenStack Logging Standards.

Change-Id: Ie277c5742ab736f4c5cee1ee1badedf055323515

Debugging the agent is a huge pain point. Tracebacks are rarely logged,
error messages are often only returned via the API, and lack of
info logging makes it hard to determine where some failures occur.
Some errors only return a 500 with no error message or logs.

Change-Id: I0a127de6e4abf62e20d5c5ad583ba46738604d2d

The docstrings here were all giving WARNINGs or ERRORs during the docs
build, and were generally making unappealing looking developer
documentation. I corrected the syntax and did what was neccessary to
make the build come out clean.

Change-Id: I74b00a7f125770b0468cff3bdf26d0d52cd054d7
(cherry picked from commit c0921cdff372ce1fd6df1c4ab4eb5463e2cba0e4)

This will add support for in band cleaning operations to IPA and
replace the decom API that was unused.

Adds API support for get_clean_steps, which returns a list of
supported clean steps for the node, execute_clean_step, to execute
one of the steps returned by get_clean_steps.

Adds versioning and naming for hardware managers, so if a new hardware
manager version is deployed in the middle of cleaning/zapping, the
cleaning/zapping will be restarted to avoid incompatabilities.

blueprint implement-cleaning-states
blueprint inband-raid-configuration
blueprint implement-zaping-states
Depends-On: Ia2500ed5afb72058b4c5e8f41307169381cbce48
Change-Id: I750b80b9bf98b3ddc5643bb4c14a67d2052239af