Key shares and consortium update

[jumaffre]

Resolves items 10 and 14 in #51

Apologies for the large PR: in hindsight, some of the following items could have been committed independently.

This PR:

• Introduces a new configuration table, which for now only contains the recovery_threshold value. This value indicates how many recovery shares are required to re-store the ledger secrets on recovery. The recovery_threshold can be set when the first node starts (--recovery-threshold parameter to cchost - defaults to the number of original members) or updated via the new set_recovery_threshold governance command.
• Updates the recovery key shares when consortium membership changes happen: a) when a new member is activated (ack RPC), they are allocated a recovery share (+ all the shares are reshuffled) and b) when a active member is retired, all the shares are reshuffled.
• You will see that they are a number of checks in places to make sure that we never end up in a non-recoverable situation, i.e. recovery_threshold > number of active members.
• I had to refactor a bunch of Python infra code to make sure that we can easily test membership changes from our e2e infra. In particular, the Consortium class was split (see new Member class) and a new Proposal class was created. Members can propose() (returns a Proposal), vote(), ack(), getEncryptedRecoveryShare(), submitRecoveryShare(), etc. while the Consortium orchestrates members, keeping track of who is active and can vote_using_majority().
• I have added new unit tests at the top of memberclient.py to test for membership and recovery threshold updates.

Still to do:

• Re-keying when a member is retired as it turns out that re-keying and re-sharing at the same time is awkward.
• Chaining the e2e test blocks created in this PR and adding them to our test suite (i.e. actually test that we can recover a network when the threshold has been updated).
• Remove sealing altogether.

[ghost]

new_share_consortium_update@7049 aka 20200406.30 vs master ewma over 50 builds from 6259 to 7022

[jumaffre]

Looks like I shouldn't have deleted one of the pbft_open parameter somewhere in the e2e infra when opening a network. This is the cause of the CI failures.