feat(governance): Batch proposal

[daniel-wong-dfinity-org]

All sub-actions must have same topic.

Topic is inherited from sub-action(s).

Implementation

To make this work, I (well, Claude, really) had to split perform_action into two separate steps:

1. try_perform_action (new), followed by
2. set_proposal_execution_status (existing)

This way, perform_batch can call try_perform_action for each sub-action, and NOT set the proposal's final execution status.

Furthermore, we also had to make sure that the implementation of every action (called by try_perform_action) did not try to set the proposal's execution status.

In particular, significant rework was needed for ExecuteNnsFunction. Such rework includes getting rid of execute_nns_function in the Environment trait. It was just a shitty version of call_canister_method anyway; therefore, deleting execute_nns_function is really not as bad as it sounds.

References

Closes NNS1-4296.

1. Behind flag.
2. No; just like for all new proposal types.
3. Existing proposals and neurons are fine.
4. Asked.

[jasonz-dfinity]

I very much like this change, but I strongly suggest splitting it into a smaller PR.

[jasonz-dfinity]

We have an existing issue that could be made worse with the batch execution - the execution of a proposal is within the same method execution as everything else (most notably, changing the execution status). That means, if the instruction limit is hit for a synchronous proposal (e.g. manage neuron) and if such proposal execution triggered through deadline, then it will keep trying. I considered this case when disabling "making proposal as part of manage neuron proposal" (cbebf5d).

I haven't gone through all the proposal types, but I suppose for most types it's not an issue. However, I can think of a case - a ManageNeuron proposals with 100 RegisterVote, and each one triggers a lot of following (sadly, for the same reason, the proposal execution triggered by RegisterVote causing an absolute majority, also executes within the RegisterVote message, and vote cascading can be expensive).

Therefore, my suggestion is to change ic_cdk::spawn=>ic_cdk::spawn_migatory (if I understood that correctly, I'm not 100% sure about the behavior of different spawn methods)

[jasonz-dfinity]

I would assume the "all actions have the same topic" validation happens somewhere below, but I can't find it.