feat: implement pallet_msa::withdraw_tokens extrinsic

[JoeCap08055]

Goal

The goal of this PR is to implement an initia withdraw_tokens extrinsic that allows MSAs holding tokens to authorize their tokens to be withdrawn to a specified account.

Closes #2388

Discussion

Checklist

• Updated Pallet Readme?
• Updated js/api-augment for Custom RPC APIs?
• Design doc(s) updated?
• Unit Tests added?
• e2e Tests added?
• Benchmarks added?
• Spec version incremented?

[codecov]

Codecov Report

Attention: Patch coverage is 89.43089% with 13 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pallets/msa/src/lib.rs	86.81%	12 Missing ⚠️
pallets/msa/src/types.rs	96.87%	1 Missing ⚠️

Files with missing lines	Coverage Δ
pallets/msa/src/types.rs	97.74% <96.87%> (-0.28%)	⬇️
pallets/msa/src/lib.rs	91.56% <86.81%> (-0.69%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[JoeCap08055]

@wilwade while examining the signature registry methods in order to split checking (read) from recording (read/write) signatures, I came up with this tiny optimization--we don't need to add the previously-most-recent signature to the larger list if it's already expired.

Double-check me on that?

[wilwade]

Yes. It took me a bit, but it works. Added a change to the comment above it to make it clear what it is doing, but that is optional.

[wilwade]

I think I take this back.

It doesn't work and apparently we don't have a test for it. I think...

It does work. See next comment.

[wilwade]

For others reading this, this might help:

The comment on the top of register_signature says this:

1,2 (oldest)
2,3
3,4
4 (pointer storage)

I thought Joe's idea is that when 5 comes in, if 4 is ALREADY expired, instead of adding 4,5 and 5 (pointer storage) we ONLY need to keep 5 (pointer storage)

However, this "breaks the loop" So does it work or not?

The answer is yes. Because: The comment is wrong/misleading. It should be

/// Example list:
/// - `1,2 (oldest)`
/// - `2,3`
/// - `3,4` (newest, is only in pointer storage)`

So Joe's actual idea is that when 5 comes in, if 4 is ALREADY expired, instead of adding 3,4 and 4,5 (pointer storage) we ONLY update the pointer storage to 3,5 (pointer storage)

That keeps the loop intact.

So @JoeCap08055 you are good to make the change, but please update the comments a bit to make it more clear (and fix my bad original commenting)

[JoeCap08055]

@wilwade (and maybe this is a bit out of scope here, but since we're messing with this algorithm anyway...) I notice that the signature storage, once it fills up, will from that point on always contain the max # of entries, even once they've all expired. Have we considered the comparative costs of maintaining that steady-state storage for all time, versus opportunistically pruning any time a new signature comes in?

(I understand that the pruning cost could end up being expensive for a single "free" transaction if we pruned all expired entries. Possibly we could strike a balance, say... any time a new signature comes in, prune the N oldest instead of just the oldest, which would lead to a, if not empty, at least lower steady-state storage cost over time...)

If this seems of interest I could write up an issue if we don't want to include here...

[JoeCap08055]

(Also, I'm going to revert my change: since, currently, storage will always => max entries, and in order to make my change work, it still needs to perform a write (update instead of insert, but same cost), there seems no need to mess with this method unless we're going to address my comment above.)