Resolve failures with cuttlefish configuration changes in Riak 2.0.
Remove riak_control_upgrade, since riak_control should cover those use
cases completely.
Wait until both the Riak Control gen_server has been registered, and the
webmachine routes have been added to the dispatcher to ensure that Riak
Control is able to service requests to prevent races between the test,
and application initialization.
Since we can't use riak_core node watcher service, we need to block
until the gen_server initializes, is available, and routes have been
added to the webmachine dispatcher.
We no longer need to test for the incompatible status in vnodes, because
the ring page no longer requires that information and can derive all
state from the ring, not rpc.
This test produces *failing* cases for Riak Control against to cut 1.4.1
release, but passes when run against a tentative master-based 1.4.2
build.
This test currently covers:
* Rolling upgrade of all nodes, while every node runs control.
* Verifies nodes do not fail during the rolling upgrade.
* Verifies two releases back.
* Verifies that 1.3+ resources return properly and deserialize.
* Verifies that 1.2+ resources return properly and deserialize.
* Intermediate and final state verification of the response JSON from
Riak Control.
* Verify convergence of capability.
This test does not cover:
* Riak 1.2 node ping, stats, and fallback resources, which are not used
by the user interface.
* Parsing the Riak 1.2 response to ensure values return the correct
state.
