junit.py was failing because it assumes h2o uses two sequential ports per jvm
H2O.java error message implies 3. I guess we use 2 so changing back. I was confused today.
I'm voting this way because it makes sense to me and useful tests pass that used to fail.
If the accepted votes say the cloud is a certain way (a "view") , and some node is in it, and then if there is a heartbeat from that guy, and he doesn't think he's in that view, the leader (or someone) should send out another Accepted message.

Currently it's conditioned more than I think it should be, currently. That leads to cases where a bad situation doesn't get fixed. (i.e. static non-fully-built cloud). The "static bad" is when the full cloud isn't formed, but no new proposals are coming from the leader. (I checked that the heartbeats seemed to be there.

This change is part of not allowing bad states to be static, and recovering from illegal states.

Basically, you don't want a secondary kind of decision making to be happening...i.e. that a node can "modify" the view, or ignore a node because he doesn't have the rght view yet. (but you got a heartbeat from him)

if there is future debate in what the view should be, the leader and proposal_num behaviors will sort it out, and a new view will get voted on.

Remember it's all about "one view". No matter where you're at, it's about having "one view" in the end. (and you keep on doing stuff until there's "one view" amongst all who heartbeat each other. Mixing hw diagnostics in the middle muddies the thinking (i.e. a half-broken node)
updated to step jvms by 2 ports not 3
everyone incs by 2 ports per jvm now
increase timeout
get rid of some unnecessary checking/waiting, to go faster
make them all have a polling interval of 2secs (retryDelaySecs)
reduce this to 8 jvms per host
don't have to inc ports between clouds any more? reuse ok?
Merge remote-tracking branch 'origin/master' into ec2