Closes #1124

Per-token reputation rate

In order to maintain some of the behaviour around payments (i.e. reputation being emitted on finalization, not claim), after a discussion with Arren, we came to the conclusion that we would limit the number of tokens that, if paid out from a colony, would result in reputation being awarded to the recipient. We landed on ten, which seems like plenty. In principle, this could be increased in the future, but only with the spectre of gas limits hanging over our heads.

The relevant tokens are stored in a linked list, and tokens must be inserted in order of ascending address in order to ensure there are not duplicate entries - indeed, when any editing of the list is taking place, the previous token must be provided.

The root permission is required to do this, for fairly obvious reasons.

An event is emitted when a token rate is set.

Per-domain reputation rate

Sadly, the same spectre of gas limits hangs over us with respect to per-domain reputation rate, given how it is intended to work (after a discussion with Arren, as this was not clear in the original issue). With multiple domains in a hierarchy, (e.g. A -> B -> C -> D), then the per-domain rate for D is equal to a factor set for D, times the factor (if any) set for C, and so on up the tree. It seems as if that the creation limit (because we note children / parents on skill creation) dwarfs this factor, but something to keep in mind.

Note that strictly, I've implemented this as a per skill reputation scaling, but only provide a mechanism for the skills of domains to be set. This gives us some latitude for the future to add per-skill scaling, but ultimately was driven by the requirement to walk up the skill tree, where it isn't possible to walk up (on-chain) the domain tree.

Again, the root permission is required to set the per-domain reputation rate. This is because of a scenario where the scale factor in a domain is set to 0, any non-root permission being allowed to set it to non-zero allows unexpected earning of reputation in root.

For both per-domain scaling, and per-token scaling, the scale factor is applied before being emitted to the reputation update log. No changes will be required once #1132 is merged as a result, and the reputation miners also need do nothing to accommodate these changes.

An event is emitted when a domain reputation rate is set.

Updates to payout scalar

Encompassing two bullet points in the requirements, permissions around payoutScalar have been changed - ultimately, those who were able to adjust it before can now adjust it between -1 and 0 (previously -1 and 1). This removes the ability to give bonus reputation using the payoutScalar. Root permission is now required to set the scalar above 0 (and can be set to an arbitrarily high value), which can be used in extraordinary circumstances to edit the reputation earned by a payment.

Per-colony decay rate

Fairly self-explanatory. I've limited the precision to the same amount of precision we have currently for the default value. Colonies can return to following our default decay rate even if they've set their own previously.

This feature will require a little additional work to sit alongside #1132, in that the function call that sets the decay rate will need to be bridged, but otherwise decay-rate calculations will occur as previously. Updates to the decay rate require one reputation cycle to complete, which is tracked by storing the address of the currently active cycle and not accessing the storage with a simple getter, but via getColonyReputationDecayRate.

The changes to the reputation miner code is such that it should be able to be deployed before the contract changes to allow a seamless transition.

An event is emitted when a colony's decay rate is set.

Other changes

I've made a few other changes on my way through this work:

• require(false, "...") replaced with revert(...)
• Change the solhint script, as IColony.sol is now too large to be piped in to solhint.
• I've changed the bn2bytes32 function to work as I expected, at least, with negative values.

Notes

I'm not 100% that I've covered all overflow guards for the scaling, so a special eye there would be appreciated.