[WIP] pallet-anchors: add precommit deposit

[lemunozm]

New changes (Specs):

• Add a Pre-commit deposit.
• Auto pre-commit eviction at commit() if successful.
• Refactor evict_pre_commit()
• Added benchmarks.

Blocked by #890

Tasks:

• Implementation
• UTs (funds)
• UTs (eviction)
• Check the correct deposit amount for the different runtimes
• Updated to use the new pallet-fees
• Add benchmarks: Benchmarks pallet-anchors #706
• Update weights: Benchmarks pallet-anchors #706 (delegated to a future PR)

Closes #865
Closes #706

[NunoAlexandre]

Code looks good!

[mikiquantum]

I am still on the fence about the deposit vs fee here bc the archiving node nature.
A few comments:

• I would add the unreserve as well in the commit call, when there is an existing precommit. The reason being that for most of the flows that call precommit before will call commit a few minutes later max (most likely seconds). This comes with extra cost, of triggering manually a eviction of the precommits, which is not straight forward since the precommits to be evicted are indexed by buckets by number and idx. But is a really bad user experience if when following the happy path a user will have to wait until someone calls (or themselves) the evict bucket call.
• The issue of not storing the PreCommitDeposit in the precommit itself is that if we unreserve after that amount has been changed by a runtime upgrade, then the user would get less/more (depending on the lock) of what it was reserved. If we go with this approach we need to store the precommit balance in the storage.

Thinking further on this, this is becoming a bit more complex, due to the nature of the eviction buckets for precommits. I am leaning more towards implementing the flat extra cost (non returnable fee) for calling the PreCommit function instead. If later on, we start seeing more usage of this function, then we can reconsider. I would keep it simple for now.

[lemunozm]

Probably this type can be removed once pallet_fees be updated with a storage key-enum based.

[lemunozm]

@mikiquantum Do we want to use a key from the pallet key for the pre-commit deposit?

[mikiquantum]

Yes, I would say so, since we already have the setup for it.

[lemunozm]

It is really difficult to accuracy benchmark this. It has two big parameters that affect the computation of this call. First, the MAX_LOOP_IN_TX, and second the number of days from the last evict_anchors call. The first one is handled. But the second one has no limit, and I do not know how to deal with it. Anyway, I don't think it is an issue, since this call is not idempotent. I mean, only the first call could have a big amount of computation, the next ones not.

[mikiquantum]

I think we should change the evict_anchor logic and simplify it to be called externally per anchor_id like we do with the evict_precommit. Lets chat more about it offline.

[hieronx]

I should have looked at this earlier, my bad, but wouldn't it make more sense to call these keys something like

AnchorCommitDeposit
AnchorPreCommitDeposit

Since there could possibly be other pre-commits in the future not related to anchors? And for consistency.

[lemunozm]

Good idea! Even we can add a sub-enum per pallet I think. Something like:

FeeKey::Anchor(Anchor::CommitDeposit);