Fix possible bias of the concrete coin mechanism with fake Responses sent to fake Requests by malicious nodes

We have identified a possible attack that would allow a malicious node to influence the concrete coin process in favour of them deciding the coin value. If exploited 100% of the time, with full knowledge of every other node's point of view, it could be used to affect Liveness of the protocol; e.g: stall consensus forever.

We already have plans for mechanisms that forbid DuplicateResponse s to the same request: https://maidsafe.atlassian.net/browse/MAID-3091 and another mechanism to forbid InvalidResponse s, e.g response to an event that isn't a Request: https://maidsafe.atlassian.net/browse/MAID-3088 .

However, we spotted an alternative way to send many Responses in a short time: create many gossip events with cause Request even though the author of these Requests hasn't actually sent a request.

To address it, we need to add a way to detect "fake Requests" and punish their malicious authors.

We discussed a few implementation options and here is our preferred route at the moment (performance analysis may make us investigate other routes as necessary).

• While sending a sync request, each node will create an event in their graph with cause: cause::Requesting(RecipientId)

• Any event with cause::Request where the other_parent doesn't have cause::Requesting(RecipientId) where the RecipientId is the author of that event with cause::Request can immediately be identified as malicious, with malice type InvalidRequest. This is a provable type of malice so the author should be punished as soon as the information propagates.

• When receiving a sync response, the recipient will create an event with cause::Response as previously; however, they will first ensure that the event with cause::Request is the unique such event created with that specific other_parent [1]. If the Request is not unique with this Requesting ancestor, an event with cause::Response won't be created, but instead an event with cause::MaliceAccusation(DuplicateRequest) will be created and that type of malice too is provable which means the offending node should be kicked out as soon as the accusation spreads.

• Accomplice detection should also be covered for InvalidRequest and DuplicateRequest

• This changes the topology of a gossip graph so we will need to update the tests with hard coded graphs (in dot format)

[1] Note: here is a way to implement detection of DuplicateRequest

• check the tip of the gossip graph for the node who sent the response. It should contain a Request event

• check its other_parent. It should have cause::Requesting(response author)

• iterate over the events created by us from that event on. For any event with cause::Response, check that this event's other_parent's other_parent is not the event with cause::Requesting we are iterating from

• If it is, DuplicateRequest was detected

• If we reach the latest event we created without hitting such a case, we're good to create an event with cause::Response