Lotus miner needs to use new prove_replica_updates2

[anorth]

Checklist

• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the lotus forum and select the category as Ideas.
• I have a specific, actionable, and well motivated feature request to propose.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

What is the motivation behind this feature request? Is your feature request related to a problem? Please describe.

This is #11139 but for prove-replica-updates.

As part of direct data onboarding we are finishing a long outstanding migration from a PRU message that does not specify CommD to one that always specifies CommD. This is achieved by deprecating ProveReplicaUpdates for ProveReplicaUpdates2.

With this change in effect the lotus miner will need to migrate its internal PRU message sending to use the existing ProveReplicaUpdates2 message that will not be removed in nv21.

Describe the solution you'd like

All calls to ProveReplicaUpdates should be replaced with ProveReplicaUpdates2. Because the sealing pipeline sector infos hold onto a pointer to CommD and this is the only difference in input parameters between old and new PRU methods, this should be a painless code change that only requires swapping out method numbers.

Describe alternatives you've considered

If we don't do this we will be blocked on doing the final stage of PRU message migration inside builtin actors. We will be unable to rely on CommD availability independent of the builtin market.

Additional context

See comments on #11139, which was closed by PR without addressing them.

[anorth]

Apologies, I was premature in filing this. The new prove_replica_updates2 was provisioned in preparation for the changes we're making in direct onboarding, but now that we've better specified those changes, I realise this explicit CommD isn't needed.

I'll discuss with @ZenGround0, but we'll in fact probably deprecate this method.