smart wallet applyMethod (e.g. for voting)

[dckc]

What is the Problem Being Solved?

DC new one: applyMethod for voting
Oracles exercise their powers by getting an invitation … offer result, on which they can submit price info
Committees work similarly. Get an offer result with a widget that lets them submit votes.

Similar work to #5974 but need this part earlier to unblock contract review. Also this contract-side code needs to be production-ready whereas the client just needs to work

Description of the Design

(Need to use the Smart Wallet for this because we’re turning off agSolo, due to security risks.)

regular action, not spendAction because we don't want it to be possible to unmarshal a reference to a purse. (no need to do a withdrawal while voting).

Security Considerations

• reject spendAction, voting should never do a withdrawal
• should we restrict method names (by length or allowlist) ? will we be prepared to upgrade when there's another use case?
• contracts should not be able to forge references to offer results (i.e. offerResults belong in a private table of an export context)

Test Plan

Try to make a committee and vote on it through a wallet

[dckc]

On closer inspection, the current acceptOffer doesn't provide the prerequisites that I thought it did... @turadg has details.

[turadg]

Idea is to have a lib-smartwallet that has a smaller API by dropping agsolo.

It will need to support more than PSM use cases though because we don't want to have to upgrade the contract for MN-1 launch with vaults. Specifically it will have to support continuing invitations (invitationMakers).

If we have in smart wallet, then the voting could use it. Instead of getting a voter facet back (e.g. { castBallotFor:) you'd get a voter kit and its invitationMakers would provide the operations like castBallotFor. lib-smartwallet would have to allow you to pass in offer args.

But should we ditch continuing invitations and just have an attenuated cap? see #3901

[Tartuffo]

We have a new design.