Fixed ordering of self.ready? tests

The self.ready? function is modeled to check if the cluster is up before making cluster config changes. Great, but this check was slow, and the probability of the cluster going down during config changes is minimal. Besides that, it didn't guarantee the cluster was still up during your config changes as the test was non-atomic.

To speed the ready check process up, caching now happens: once the cluster was detected to be up, we assume it'll stay up.
The test checked first if self.ready would return true when up (yes), and then when self.ready returned true when the cluster was down. In the last case, we'd have to return true, because it was up before. 

By switching the order of these tests, actual cluster behavior is modeled more closely.