wait for link status change when calling Device.up()/down()

[jtluka]

Possibly relates to #100

We should inlude a check of the link state when Device.up/down() methods are called. Without it there is a race condition possibility when proceeding with tests that depend on the network reachability, for example ping test.

We could add this as a common recipe api similar to what we have in BaseEnrtRecipe.wait_tentative_ips() or add it to Device api, that seems more appropriate.

The check can be done by calling:

$ cat /sys/class/net/enp0s20f0u2u1u2/carrier # link is up
1

$ cat /sys/class/net/enp0s31f6/carrier # link is down
0

[jtluka]

Probably can be done through Device.state property: https://github.com/LNST-project/lnst/blob/master/lnst/Devices/Device.py#L468

[olichtne]

imo this should be two different actions, possibly joined into one more "bigger" methods of up_and_wait and down_and_wait for convenience.

the problem being that the up method literally just sends a REQUEST to the kernel to set the state to UP, however, the way that the netlink protocol is designed, this isn't guaranteed to work, AND even if it works, it's not guaranteed to get a response.

You can even get a response that the REQUEST was successful, but the state stays down for example...

So i think the API should be carefully made to be as explicit for these situations as possible:

1. i think we should have the most basic wrapper methods as normal - up and down just send the request, as is the current state and this also mirrors what ip link set up does - it only sends the request, nothing else
2. we can add a helper wait_for_state or wait_for_condition methods that implement some time restricted loops to check for a condition
3. we can then add convenience methods that merge some common actions with a common condition that often times follows that specific request/