Taking over from https://github.com/maidsafe/routing/pull/1856 Implement part of https://github.com/maidsafe/routing/issues/1835

This implements the logic for promoting and demoting Elders as needed and updates the splitting logic correspondingly.

Rename

• vote -> proposal
• consensus -> agreement
• accumulate -> aggregate
• Stage -> Dispatcher
• Approved -> Core
• handle_XXX_event -> handle_XXX_agreement

Implements RFC-0023.

Allow all ImmutableData type managers to obtain a copy of a chunk from any ImmutableData type manager by applying a deterministic naming scheme to the 3 ImmutableData types.

Refer to https://github.com/maidsafe/rfcs/blob/master/proposed/0023-immutable-data-type-naming/0023-immutable-data-type-naming.md which includes the code used in this PR.

This change is   Multiple assignees:  Fraser999,  afck,  dirvine,  maqi

I assumed that any code not used internally was to be removed. I also assumed the commented tests were to be removed. I hope these were acceptable assumptions to make.

Everything remaining is currently used in the main build or the tests.

In RT print routine, compute average of section length multiplied by 2 ^ section prefix length. This gives an estimation of the total number of nodes in the network. Display also the potential deviation given by max and min values.

This implements this idea proposed in this post in safe forum.

debug output using routing master (at v0.2.8) and crust (v0.2.1)

Handle find group response Sending ConnectRequest to peer ae12ce..b47a4d New CONNECTION; Tcp(V4(127.0.0.1:53078)) CRUST::NewConnection on Tcp(V4(127.0.0.1:53078)) Register unknown connection; Tcp(V4(127.0.0.1:53078)) Send IAM; Tcp(V4(127.0.0.1:53078)) Sending IAM; Tcp(V4(127.0.0.1:53078)) New Message; Tcp(V4(127.0.0.1:53078)) New NON_SIGNED ROUTING MESSAGE; Tcp(V4(127.0.0.1:53078)) Handle I Am Handle I Am Relocated; Tcp(V4(127.0.0.1:53078)) RT (size : 1) added connected node ae12ce..b47a4d on Tcp(V4(127.0.0.1:53078)) Handle CHURN new node ae12ce..b47a4d RT: 31465a..e5f0d2 RT: ae12ce..b47a4d New CONNECTION; Tcp(V4(127.0.0.1:53083)) CRUST::NewConnection on Tcp(V4(127.0.0.1:53083)) Register unknown connection; Tcp(V4(127.0.0.1:53083)) Send IAM; Tcp(V4(127.0.0.1:53083)) Sending IAM; Tcp(V4(127.0.0.1:53083)) New CONNECTION; Tcp(V4(127.0.0.1:53088)) CRUST::NewConnection on Tcp(V4(127.0.0.1:53088)) Register unknown connection; Tcp(V4(127.0.0.1:53088)) Send IAM; Tcp(V4(127.0.0.1:53088)) Sending IAM; Tcp(V4(127.0.0.1:53088))

This PR replaces the message backlog mechanism with message bouncing:

• Consider two nodes, A and B.
• A sends a message to B (it can be a message originating from A or its section or a message that is just relayed through A)
• B receives it but can't handle it because it isn't in the correct state
• B wraps the message in Variant::Bounce and includes the version of its own section according to its knowledge. If B is not yet member of any section, it sets it to None.
• B sends the Bounce back to A
• A compares the version in the Bounce with the version of the section B is a member of, according to A
• If the bounce version is lower than the known version, that means that B is lagging behind. A then schedules the message to be resent after a short delay (currently 1 second)
• When B receives the message again, chances are it has already caught up and is able to handle the message now. If not, it sends the Bounce again.
• If the bounce version is the same or higher, or if B is no longer a member of any section known to A, then A discards the message

This PR also modifies the incoming message filter to support the above flow: messages are now inserted into the filter only if they are handled. If they are only relayed and/or bounced, they are not filtered. This modification was necessary, otherwise the resent messages would get filtered out.

Finally, this PR includes minor refactoring / code cleanup.

Closes #1941

On Windows, I ran the simple_key_value_store example. There was no network to connect to, and I retried with my machine's network cards disabled to be sure.

On starting the example with no args, no indication is given whether or not it has connected to a network.

If I subsequently tried to Put or Get, the example crashed with output:

thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value'

Rename Agreement -> Dkg as it is Dkg we do the agreements via messages and here we should only be updating section chain and SAP with different members (handling churn)

BREAKING CHANGE

Running multiple instances of key_value_store as a node we're seeing all connecting to the first but not to each other. If we run a client it also connects only to the first, while storing a value is only stored the first.

Limit the number of prospective nodes in the bootstrapping process to one per proxy node.

We also disabled the direction check for now, since we found that it makes the ci_test less reliable. This is to be expected since the notion of a "close node" is currently ill-defined, but we should consider re-enabling it once that issue is fixed.