feat: extend datacap expiration

[swift-mx]

Related Issues

This is Droplet extend datacap expiration function https://github.com/ipfs-force-community/droplet/blob/a9bceef4afcd3141ee929e72483ba2f812069c02/cmd/droplet-client/datacap.go#L35

[LexLuthr]

@swift-mx Can we please increase the scope of this PR to cover all cases of the claim extension?

1. Extend all claims for a miner ID

2. Extend all claims for multiple miner IDs

3. Extend specified claims for a miner ID

4. Extend specific claims for specific miner ID

5. In case, wallet address is different from claim.Client then we should filter out such claims and in the end ask client if they wish to extend such claims as well. Extending such claims require client to send an allocation message and client will end up spending the data cap. This could be a prompt with all the info and final data cap requirements asking client to choose between "Yes" or "No". You can also add a --force flag to skip this check.

TermMax should default to verifregtypes.MaximumVerifiedAllocationTerm if not provided by the user.

We should encourage client to set TermMax to MaximumVerifiedAllocationTerm. A client has already spent the datacap. I don't see a lot of reasons (apart from client internal policies) to not use the maximum allowed. It costs nothing to client and SPs get 10x power till TermMax. It also saves gas as we will sending just 1 message.

Apart from this, we should also align to use terminology defined in Actors.

The expiration-cutoff also doesn't seem very logical. What scenarios would require me to extend my claims on periodic basis. It seems like a waste of gas.

[LexLuthr]

Please note that we have one more PR to implement claim extension #11545

I would request you and @nicelove666 to work together to avoid duplicating efforts and expanding the scope of the command as requested.

[beck-8]

#10001

[LexLuthr]

Closing this there has been no input from author. #11711 supersedes this now.