feat(x/provider): consumer fee pool deposits with per-depositor shares

[giunatale]

closes #37

supersedes #37 with a share-based per-depositor design: every deposit mints shares for the signer (or, for gov-authority deposits - meaning funding from community pool, for the distribution module account). Each depositor controls their own withdraw, the consumer owner can trigger a pro-rata sweep. Auto-sweep on consumer delete settles the pool.
A bank.SendRestriction rejects bank transfers to fee pools so the share accounting can never drift from the pool balance.

See docs/consumer-fee-pool.md for more details.

[julienrbrt]

Allowing the depositor to arbitrarily withdraw their funds could deceive others thinking they are enough funded for validation. The depositor could pull out the funds and basically censor the chain until someone else re-add funds.
Tbf I think funds should be only clawed back when the consumer chain shutdowns (and to make it simple to the proposer).
If someone made a substantial mistake, then they can always ask governance to do that manually.

[giunatale]

Allowing the depositor to arbitrarily withdraw their funds could deceive others thinking they are enough funded for validation. The depositor could pull out the funds and basically censor the chain until someone else re-add funds. Tbf I think funds should be only clawed back when the consumer chain shutdowns (and to make it simple to the proposer). If someone made a substantial mistake, then they can always ask governance to do that manually.

governance should not get involved here.
WDYM with Allowing the depositor to arbitrarily withdraw their funds could deceive others thinking they are enough funded for validation. The depositor could pull out the funds and basically censor the chain until someone else re-add funds.?
I don't understand the deception case, I mean ok but also what do you actually achieve?
Regarding the "censor the chain" I also don't understand, if a depositor is pulling out funds, it means conviction/interest to fund the chain's continued operation disappeared. If the depositor pulls out the funds, it's the owner/chain's duty to fund it.
What if the community pool is providing a subsidy, but the chain didn't perform and they want to pull support?

[julienrbrt]

My point was about the share tracking, which I don't think is necessary. Governance should not overfund a chain, that isn't capital efficient. Governance could be allowed to claw it back on shutdown.

By censoring I mean, if a depositor deceived everyone to believe the chain was well funded and pull out liquidity for enabling the ante handler that blocks all txs, imho it is censoring the chain. I know we are talking about a super edge case requiring social engineering, but that was my first thought 😅 so I had to mention it. I do agree that is it quite far fetched.

Generally I just find the system more complex while we could keep it KISS.

If we do go with that, the code lgtm, we should make sure to have a minimum deposit to prevent state bloating because of dust

[giunatale]

I don't disagree that this system is not necessarily simple, and I appreciate the pushback.

The approach taken here is the result of discussions started in #37 and then in a call with @tbruyelle.

Regarding

governance should not overfund a chain

governance moves slowly, so preemptive (larger) allocation isn't necessarily out of the question. Moreover, auto-sweep (claw back) on shutdown is not the use case I was thinking, but before a shutdown.

and in any case, there needs to be some form of accounting because otherwise we are handing power either to the owner of the consumer or the provider governance over all funds, and to me neither is correct.

Believe me I also am not happy with the implementation here, it's definitely not KISS. But as I wrote in #37 the more I thought about it the more I got convinced that "the simple solution is a bad solution".

We should have an open-ended discussion with you and Thomas. I am not against scrapping all-or-part of this solution, but I want to be convinced a simpler alternative is better (not from an engineering standpoint).

[tbruyelle]

This is a first round of review before the next changes related to our discussions

[giunatale]

added locks for withdraw/sweep if chain is launched. In any other state funds can still be withdrawn (so a little different than just allowing when stopped, but imho logically more sound). Authority has a bypass and can still withdraw at launched state

added minimum deposit check with a param multiplier used to compute the min deposit when multiplied by the fees_per_block. Preferably better to merge #47 first so this PR can be updated to match the changes in #47.

Also addressed @tbruyelle feedback (lmk if looks good) and merged master

[tbruyelle]

LGTM!