p2p accounting

[holisticode]

This PR introduces the first phase of p2p accounting for message exchange, which forms the basis for swarm's incentivization layer and accounting.

This current implementation only does the accounting part, no cryptoeconomic features are implemented yet (price negotiation, claim settling, etc.). This means this implementation just keeps track of how many units are exchanged between nodes and maintains a balance with them.

Basic design:

p2p/protocols/accounting.go defines the basic interfaces:

Balance defines the actual accounting interface. It only has an Add function. This function will be called with a peer instance and an amount. If the amount is negative, then the local node is being debited, if it is positive, the local node is being credited.

Prices is an interface that defines how prices are being expected. Every accounted protocol should provide an implementation, and return a Price structure for every message for which it requires accounting. This struct contains a Value uint64 field, which represents the price for that message. The PerBytes bool field specifies if the message needs accounting based on the message size, and the Payer Payer field defines who is to be charged for a message, if either a Sender or the Receiver.

An accounted protocol needs to provide a Hook inside its Spec, where it defines its messages. The Hook contains a Balance and a Prices interface, which allows the messaging infrastructure to transparently do the accounting.

[nonsense]

Maybe I am missing something, but it seems we are introducing a bunch of interfaces (Prices, Balance), without having a simple implementation for them, let alone a few different implementations to prove that we actually need those interfaces.

I am afraid that without concrete implementations we might be choosing the wrong abstractions.

The simulation tests kinda show how these might be used, but if this is the case, why not add those concrete implementations to Swarm now?

[nonsense]

A better name for this would be bookkeeping or something like this. doMetrics sounds like we are not keeping financial records, but rather measuring for the purpose of monitoring the system.

[holisticode]

but rather measuring for the purpose of monitoring the system.

This is in fact what we are doing here