feat: support cancellable context to interrupt proof generation

[txhsl]

Currently, for example, when we call Prove() in Gnark, we are not able to interrupt the computation and have to wait until it returns. If the proof generation is quite time-costing or the physical machine is lack of performance, then this may become an issue.

In Golang, we can't stop a Goroutine from outside, and need something like context.WithCancel to stop it softly.

[ivokub]

Thanks for the report. We have thought about it, but have currently decided against implementing it. There are mainly two reasons:

1. Performance - the long-running parts of the computation is multi scalar multiplication and number theoretic transformations. For MSM we could in principle check if the context has been canceled in the bucketed method, but NTT is a single recursive routine which is quite heavily optimized. Adding context cancelation checks there would add significant overhead and make the proving less performant.
2. Optionality - for the use-cases we have envisioned it doesn't make much sense to timeout at proving time, as proof computation is not really an optional scenario in many use cases.

I could see that for example in remote proving approaches it could be useful to be able to cancel the proof computation, but I'd rather recommend erroring before running proof computation instead based on heuristics (key size, CPU utilization etc.).

What are the use cases you would be interested in where soft cancel would be useful?

[txhsl]

We are using local proving in decentralized key generation, and this service is regularly called to refresh the generated key group.

Proving is enforced, yes, but it's somehow inconvenient in stopping to upgrade the left part of the code. Furthermore, if our users try to kill the service enforcedly, there also is a possibility that some data get lost in this process.

We have thought about it, but have currently decided against implementing it.

We will try to implement a cancellable context in our library, on top of Gnark, since we are going to upgrade to a recursive plonk solution. Hope that will optimize our user experience.

Anyway, thanks for your quick feedback!