Add method that allows us to poll server until it matches the expected value

[aljazkosir]

wait_for allows us to poll server until it matches the expected value, we can also set parameter which values we don't want to expect. Method will timeout after some specified time.

We can wait for a value in current level of object like so:

root.Systems.Members[0].wait_for(['PowerState'], 'On', timeout=30)

or for nested key:

root.Systems.Members[0].wait_for(['ProcessorSummary', 'Status'], {
             "State": "Enabled",
             "Health": "OK",
             "HealthRollup": "OK"
         }, timeout=30)

Method would be useful in cases where response from the server is asynchronous. For example when we are executing system reset actions, we want to wait for the desired PowerState value before continuing.

\cc @miha-plesko

[aljazkosir]

@tadeboro, @miha-plesko I updated the commit with the suggestions.

[aljazkosir]

I agree with @miha-plesko, some sort of dot notation would be clearer for this method, we can also make dig work that way so it's consistent, if @tadeboro agrees I can make the changes.

[miha-plesko]

I wouldn't modify dig, it's an internal function and probably there was a reason to implement it this way. The "dot" notation for wait_stats, however, is exposed to end user so I'd do it. BTW it can't be really "dot" notation because dot can be part of a valid key name. Can you please check the standard if : is ok? I think keys have to be URL-like so columns should do.

[tadeboro]

I would avoid doing any splitting in our code, because this means that we "blacklist" the keys that contain a separator. For example, waiting for a field Members@odata.count to drop from 12 to 11 will fail spectacularly if we split on .. And changing a separator will not solve this problem, since we have no control over the key content.

If changing the order of parameters is not an option, I would then go and "force" user to provide tuple as a first argument or make value a required keyword argument.

[aljazkosir]

First parameter is now expected to be a list/tuple with keys and second parameter is the expected value.

[tadeboro]

@aljazkosir Thanks for your effort.