swarm/pss: Message handler refactor

[nolash]

This is the first in a series of PR providing the following enhancements to PSS:

Send fully addressed messages to neighbourhoods

The possibility of sending a message with full PssAddress to a neighbourhood of nodes, by interactive with the Kademlia. The primary use case is chunk syncing, where the chunk will have full address but nodes that have responsibility for storing the chunk should still regard themselves as recipients of it.

Mitigate external influence of resource expenditure

If receiving raw messages, currently all raw messages will be passed on to handling code, effectively passing the responsibility of limiting resource expenditure to the handlers. This can be risky, in case of implementations that do not protect against request flooding. Whether to handle raw messages or not should therefore be explicitly set on the handler.

This also pertains to symmetric decryptions, were all registered symmetric keys (for decryption) share the same LRU cache which is tried sequentially on the decrypt. Instead, there should be symkey decrypt caches per topic.

Symkey filter in message type

To reduce resource expenditure in symmetric decryption, an extra field in the message type will be introduced where up to 32 bytes of symmetric key hint can be added. The hint is a hash of the symmetric key, indexed on both sides. The symkey cache must be refactored to be able to take advantage of this hint. A zero-value in this field would indicate public key crypto.

This also clears the way for upgrading whisper support to v6, as one of the changes in whisper v6 is omission of the symkey nonce in the whisper envelope; with this field it's still possible to identify incoming symmetrically encrypted messages, to avoid a forced attempt of asymmetric decryption on every reception.

Part 1

protocols, handshakes, pss/client and notify have all been edited to pass tests with the new Handler struct, but need to be revisited for implementation details. This will follow in a later PR

• - Change Handler from func to struct with necessary params
• - Set raw message allowance per handler
• - Add possible recipient logic to use kademlia depth
• - Handler capabilities tests
• - Prox destinations tests
• - Make sender handle message if topic has prox handler and is possible recipient

---

The PR also replaces the -v[v] verbosity flags for tests with --loglevel flag that sets the loglevel explicitly, and default level to 2 (log.Warn).

[nonsense]

This doesn't appear to be used.

[nolash]

Earlier we agreed that we should use chained constructors for setting operating modes on objects, and clients will need a way to set these properties.

[nonsense]

This doesn't appear to be used.

[nonsense]

Why do we need a warning here, and what will it help us debug if it happens?

[nolash]

The intention is that we are warned if the topicHandlerCaps flag tells us we shouldn't have a raw/prox handler, but in fact there is one. This condition shouldn't exist.

[nonsense]

Why do we need a warning here, and what will it help us debug if it happens?

[nonsense]

This can be simplified, the first conditional is redundant.

[nolash]

Well spotted, sir. Thanks.

[nonsense]

This can be simplified, the first conditional is redundant.