Optimise gas use for `ExtendSectorExpiration2`

[rvagg]

(Moved from #1598 (comment) after I realised we're talking about a slightly different thing, I jumped the gun).

Yesterday someone was asking about gas usage of "sector extensions or recoveries". I had a quick look at some example messages for ExtendSectorExpiration2, which involved verified claims, and came to the conclusion that we should absolutely look at optimising them for that case at least.

bafy2bzaceaqaxndnsczslx3cx35q6tluaisidgs36ipxsemksaqafehlcifuy is one such message:

• 402 separate calls to verifreg here
• 33% of the gas is spent in the miner actor, the majority being storage gas writing new sector infos out which is understandable.
• The rest is divided by 402, so it's lots of small cuts from executing wasm.

They all look like some variation of this:

Subcall (f02301➜f06) gas charges:
┌───────────────────────┬───────┬─────────────┬────────┬─────────────┬────────┬───────────┬────────┐
│ Type                  │ Count │ Storage Gas │     S% │ Compute Gas │     C% │ Total Gas │     T% │
├───────────────────────┼───────┼─────────────┼────────┼─────────────┼────────┼───────────┼────────┤
│ OnActorGetRoot        │     1 │           0 │   0.00 │         300 │   0.01 │       300 │   0.00 │
│ OnBlockCreate         │     1 │         662 │   0.05 │         209 │   0.00 │       871 │   0.01 │
│ OnBlockOpen           │     7 │       67320 │   4.88 │       48900 │   0.91 │    116220 │   1.72 │
│ OnBlockOpenBase       │     7 │     1312080 │  95.07 │        2100 │   0.04 │   1314180 │  19.50 │
│ OnBlockRead           │     8 │           0 │   0.00 │        4656 │   0.09 │      4656 │   0.07 │
│ OnBlockStat           │     1 │           0 │   0.00 │           0 │   0.00 │         0 │   0.00 │
│ OnGetActorCodeCid     │     1 │           0 │   0.00 │           0 │   0.00 │         0 │   0.00 │
│ OnGetBuiltinActorType │     1 │           0 │   0.00 │           0 │   0.00 │         0 │   0.00 │
│ OnHashing             │     2 │           0 │   0.00 │          42 │   0.00 │        42 │   0.00 │
│ OnMessageContext      │     1 │           0 │   0.00 │           0 │   0.00 │         0 │   0.00 │
│ OnMethodInvocation    │     1 │           0 │   0.00 │       75000 │   1.40 │     75000 │   1.11 │
│ OnReturnValue         │     1 │           0 │   0.00 │           0 │   0.00 │         0 │   0.00 │
│ OnScanIpldLinks       │     8 │           0 │   0.00 │      114815 │   2.14 │    114815 │   1.70 │
│ OnSyscall             │    24 │           0 │   0.00 │      336000 │   6.27 │    336000 │   4.99 │
│ wasm_exec             │    26 │           0 │   0.00 │     4304317 │  80.33 │   4304317 │  63.88 │
│ wasm_memory_grow      │     1 │           0 │   0.00 │       26215 │   0.49 │     26215 │   0.39 │
│ wasm_memory_init      │     1 │           0 │   0.00 │      445645 │   8.32 │    445645 │   6.61 │
│ Total                 │    92 │     1380062 │ 100.00 │     5358199 │ 100.00 │   6738261 │ 100.00 │
└───────────────────────┴───────┴─────────────┴────────┴─────────────┴────────┴───────────┴────────┘

filecoin-project/ref-fvm#2102 is related to this, there's likely ways to reduce that call cost. But what we really should be doing is batching these calls outside of that inner per-sector loop.