new api to calculate arbitrary forks revert and applys

[jsign]

This PR adds a new API endpoint and implementation to get a similar output of ChainNotify but for arbitrary from and to.

The motivation for this is the following:

• A client is following the chain to build up some index or view about it.
• The client stops their service.
• In the meantime, the chain can fork from the last known tipset for the client.
• When the client resumes, it can't use ChainNotify directly since it inspects changes from the current head of the lotus node.
• The client should check if the current head is in the same chain from his last known tipset, because if that isn't the case, it will apply new blocks using (what could be described) the wrong state.

The whole point of this API is to allow a client to provide his last known tipset, and some other new one (most probably, ChainHead), and do whatever is necessary to move on.

This API it's a bit more generic than this use case and can compare any two tipsets. Preferred doing it this way, than assuming will always compare to tipset of the heaviest chain.

TBH, I'm not quite sure that names or package where I made the changes are the correct ones, so there's a high chance that might be better to rename and/or move. If that's the case, I'm happy to fix it.

---

I thought about modifying ChainNotify to receive a from value, but realized that this way may be more orthogonal and allows resolving other cases other from current head.

I'd imagine being common a combination like the following:
Call ChainNotify, get the first Current type value, and call ChainGetPath to resolve using his from with the current head as to. The last call will give enough information to fix a possible unknown fork, and then it would continue listening to ChainNotify results as usual.

---

I chose some arbitrary maximum chain height for the fork to put a cap on the worst-case scenario. Maybe there's other more reasonable value.

[Kubuxu]

You can use build.ForkLengthThreshold as the limit.

[whyrusleeping]

We should probably just reuse code from the ReorgOps method, it does a good hunk of this already

[jsign]

Definitely, good that you mentioned it. It doesn't cover some cases I checked explicitly, but it's doing the important work (an error in those cases). Most of those things shouldn't happen in any reasonable scenario so it should be OK. I'll call that and then just do the remaining transformations.

[jsign]

Do you think may worth to add the build.ForkLengthThreshold cap to ReorgOps?

[whyrusleeping]

Probably worth adding that in, yeah. Maybe pass it as a parameter?

[whyrusleeping]

Probably good to add the limit to ReorgOps, but i'm happy to merge without that (since this is a user initiated action in any case). Let me know

[jsign]

Actually, I think it might be better not doing the check. Since chains are named left and right, it might not be that clear what is really the semantics of fork height. If right is actually the current head, that makes sense (left height from base tipset is the fork height).. but this is a quite generic method.

[whyrusleeping]

SGTM