Fix race with multiple chef-client runs

Filter out all nodes which are currently rebooting to fix a possible race.
The race is possible when a proposal is applied *and* then the chef-client
daemon triggers a run.
This leads to the situation that the client run (triggered by crowbar)
waits until the other chef-client run (triggered by the daemon) finished
and then the chef-client (triggered by crowbar) starts - but the other
chef-client (triggered by the daemon) already triggered the reboot.
> To me, what's happening is that:
> 
>     a chef-client is already happening
>     our chef-client blocks; it does indeed reset ththe attribute about reboot, but it's irrelevant anyway because our chef-client is interrupted by the reboot and therefore exits with non-0, which means we don't wait for the reboot
>     we try again with the badones thing, and since the node is rebooting, it doesn't work

"our" chef-client is the one started by crowbar, right? Assuming that, you description is right. And at the end, we get an exception.

The question is how you can differentiate between a Exception from a failing chef-client (for whatever reason) and an exception because the node is rebooting. The latter one isn't really an error. 
The proposed changes just skip the chef-run for nodes which are currently rebooting. The chef-run is done after the reboot by `crowbar_join` anyway. Why do you want to run chef-client if you already know that it will fail?