Document Superfluid state machine itself

[czarcas7ic]

Assigned to @ValarDragon for coming up with some plan for how to improve from here

[ValarDragon]

Describe the overall flow of the superfluid module.

We should make a description that describes the goal (allow LP shares / defi items to help secure consensus in staking). And then note how we achieve this, by using four things:

• Guaranteed lock durations from the underlying lockup module
• Intermediary accounts, noting that rewards are linear based on how much you have locked for a given (validator, denomination) pair.
• Tracking the amount you have superfluidly staked using the lockup module
• Using the existing gauge reward system for paying out SFS rewards

Details

Then the two main pieces of complexity we should talk about are:
(1) SFS requires actually minting new osmo (also why, and why its safe)
(2) How daily refreshes to staked amount work. Its probably useful to ideate a diagram here, to show that on epoch, we read from the lockup module how much GAMM token we have locked. We get the new oracle price. Then we see is that more or less than we have delegated. If more, mint osmo and update amount delegated. If less, do some 'instant undelegations' and immediately burn.

Then describe at a high level how bonding, unbonding and slashing works.

Bonding:

• Should talk about the osmo minting
  Unbonding:
• Moves the tracker for unbonding, allows the underlying lock to start unlocking if desired
  Slashing:
• Gathers who was SFS delegated to the validator at the height. Slashes their underlying lock collateral.
• At the moment we do the weaker security thing, of slashing at latest price rather than old price.
  Bank:
• Osmo supply queries are preserved

State machine

Then describe how every message is processed, hook is dealt with, and epoch update works. (This may just be refining whats already written)