Provide the scaffolding for the automation of reward distribution

[annatorok]

We need a smart contract (on chain, in bnsd entity) that, when sent tokens, reads the termdeposit configuration, performs some calculations, and sends tokens based on the calculations.

The flow of tokens to which this issue refers is Reward Account -> smart contract -> Depositors. This issue is only about creating the scaffolding and is not intended for production deployment, so if we can just have the smart contract read the termdeposit configuration and distribute equal proportions of the sent tokens to the addresses with a CustomRate in the config then we'll be all set.

Goal:
Smart contract should be able to read configuration and distribute tokens that are sent to it.

[husio]

x/distribution is a good place to start. Once a Revenue entity is created,
funds can be transferred to that revenue and released later. Releasing funds
distribute them among all participants.

weave/x/distribution/handler.go

Lines 127 to 129 in 888eecd

	if err := distribute(db, h.ctrl, rev.Address, rev.Destinations); err != nil {
	return nil, errors.Wrap(err, "cannot distribute")
	}

To move funds, cash controller is needed. Cash controller is provided during
handler creation and referenced by handler instance.

weave/x/distribution/handler.go

Line 98 in 888eecd

ctrl CashController

To configure an extension we use gconf package. I provides tooling and code
to make configuration management an easy task. To read a gconf managed
configuration, use gconf.Load function

weave/cmd/bnsd/x/preregistration/configuration.go

Lines 14 to 20 in 888eecd

	func loadConf(db gconf.Store) (Configuration, error) {
	var conf Configuration
	if err := gconf.Load(db, "preregistration", &conf); err != nil {
	return conf, errors.Wrap(err, "load configuration")
	}
	return conf, nil
	}

Anything can have a weave address associated. In x/distribution extension,
each Revenue entity owns a unique wallet to store funds. It is up to you to
decide how do you want to construct that address.

weave/x/distribution/model.go

Lines 93 to 95 in 888eecd

	func RevenueAccount(key []byte) weave.Address {
	return weave.NewCondition("dist", "revenue", key).Address()
	}

There are no triggers in weave. Code should not react on generic events. This
means that reacting on funds transfer is not part of the design. Creating a
hook that will execute certain function when funds are sent from/to certain
address was never the design goal.
There are at least two ways such hook could be implemented:

1. Wrap cash controller with additional functionality. This is how the burn
   wallet functionality is implemented
   

   weave/cmd/bnsd/app/cashctrl.go

   Lines 27 to 38 in 888eecd

   	func (c *CashController) MoveCoins(store weave.KVStore, src weave.Address, dest weave.Address, amount coin.Coin) error {
   	if err := c.ctrl.MoveCoins(store, src, dest, amount); err != nil {
   	return errors.Wrap(err, "move coins")
   	}
   	if dest.Equals(burnWallet) {
   	empty := cash.NewWallet(burnWallet)
   	if err := c.b.Save(store, empty); err != nil {
   	return errors.Wrap(err, "cannot flush burn wallet")
   	}
   	}
   	return nil
   	}

2. Create a middelware/decorator that will introspect each processed
   transaction and execute a hook function if needed.

Although it is possible, it is recommended to always trigger functionality with
a message. Instead of implementing hooks, require to explicitly request a state
change. This is how all our functionality is implemented.

Is this description good enough? I think it has more value that writing a fake extension that does not work.