Added member ports summary in Timeline proposals
changing doHeartbeat to always call addProposedMember(h20) with incoming node. Currently it's conditioned on "not in cloud". Commented out the old position, in case we need to return to that.

    // Failing case would be if our cloud had a better(lesser) leader than our current LEADER
    // If we never updated LEADER to that better value, we can have steady state with different nodes having
    // different LEADER values.
    // Since we ignore proposals not from LEADER, that's a steady state fail.
    // So always try to add all incoming heartbeats to PROPOSED_MEMBERS to guarantee that we
    // always have LEADER matching what others see. (or we could compare LEADER to cloud[0] when we
    // add a cloud..that would be better performance wise. Or just an assertion, but
    // this was simpler/more of a guarantee.

    addProposedMember(h2o);

passes my 2 machine home testing. as good as anything yesterday. No fails. Maybe this will help Michal's failure from today. Although I still think the problem of cloud id/cloud member Accepted packets may need to be addressed (discussed with cliff)

Note the change doesn't change the theoretical underpinnings of how the overall algo should be working.
in doAccepted, there as a clause for doing nothing if it was thought you already got a the Accepted for a particular cloud id...
change to: (see my theory on the doHeartbeat issue with inconsistent jamming of Accepted packets)

    // kbn: For now, take them all Accepted packets because the sending of
    // doAccepted cloud id + member list may have wrong info sometimes?.
    // Can reenable this when you think the Accepted packets are always perfect.
    // i.e. the cloud id and members list always matches the first time you sent that cloud id
    if ( 1 == 0 )
    // if( proposal_num == PROPOSAL_MAX && state.uuid().equals(H2O.CLOUD._id) )
      return print("do  : Nothing: Accepted with same cloud membership list",members,state);
byte order of IPv4 address
ipv4 compareTo: If the unsigned 32-bit x and _key have different sign bits, the 32-bit signed comparison needs to be reversed. Alternatively, converted to long for the substract, and back to int for the result return. Port compare was fine.
allow zero coefficients on the result for test_GLMGrid_hastie.py. update pretty printing of coefficients now that column_names is correct and just inputs, in GLM json response.
H2O only uses 2 ports, removed mention of 3rd port from error message
looks like large # of jvm on single machines works now. stress with 17 to 25 jvms. Also test for looping oncloud of 5 which has been an interesting case
some cloud and parse tests, trying parse without waiting for the result (small files)
test_parse_small_nopoll.py has a storeview that causes a NPE
trying to force the NOPTask assertion errors
reenable the storeview that causes the problem
Merge remote-tracking branch 'origin/master' into ec2