all: first working SWAP version

[mortelli]

This PR contains a first working but experimental implementation of SWAP incentive system which aims to ensure fair use of bandwidth in the Swarm network.

The system works as follows: Swarm nodes communication and data exchange is tracked and recorded into balance books. As nodes cross hardcoded balance thresholds, signed cheques are sent to the remote peers and cached out on chain through chequebook smart contracts.

This first implementation in general assumes a happy flow. Next steps will be to refine it on several aspects and to better address error scenarios.

---

TODO:

• Address all TODOs, and clearly mark those that are not easy to address, so that we can discuss or create issues if necessary.
• Implement correct balance handling and remove resetBalance
• Clean up the SimpleSwap naming (either rename the smart contracts or refactor the contractReference.Instance)
• Clean up the log calls to be following our style (log.<Level>(msg, key1, val1, key2, val2,...))
• Use structured logging:

		log.Info(fmt.Sprintf("balance for peer %s is %d", peer.ID(), s.balances[peer.ID()]))

should be

		log.Info("balance for peer", "peer", peer.ID(), "balance", s.balances[peer.ID()])

• Review logging levels - INFO vs DEBUG vs TRACE. We don't have concrete rules, but probably best to avoid using INFO for debug messages. Review ERRORs - every ERROR in our gateways nodes should be reviewed by a developer, once code goes to production. We should strive for very few/no errors.

[zelig]

jusy some preliminary comments as i went through quickly

[acud]

so... first pass from my side. there's a lot of code here. I'm not a big fan of these huge PRs and I am still adamant that this could have been broken into smaller pieces of work that are easier to reason about and that could be merged directly into master.
Comments in a nutshell are:

1. lots of aesthetic changes that need to be done, mostly in the realms of logging and error handling (i.e. dont log errors then return them).
2. Probably unnecessary use of pointer semantics in some cases (do you need to change params on-the-fly?)
3. Passing private keys around - I am not a big fan of this. I'd rather see this functionality in some core component that handles the keys
4. You have generated bindings but the solidity files are not here - why? and where's the tooling to keep both on par? I suggest you add the solidity files to be in the same repository
5. Some unwanted full-database-scan functionality on the state store - I explicitly don't like it. you should know what you're querying for. and if you don't - you should at least construct correct indexes that would allow you to iterate over the keys you KNOW you want to have. leveldb is not a SQL database. please bear that in mind, and by the looks of it - the usage of that functionality might cause us trouble. If you're unsure on what is being requested of you - please ask and we will kindly guide you to the correct solution.