Reduce cloning overhead

[Nashtare]

Alternative to #81 for reducing the overhead of GenerationInputs cloning. The rationale is that once the inputs have been processed, some are unneeded to carry on with witness generation / proof execution, and can be trimmed off, alleviating the downside of cloning. Also some method signatures have been changed to take a reference to the GenerationInputs.

Could actually be done against main, but continuations branch has done some changes around, so probably better to just redirect this tweak there.

[LindaGuiga]

Looks great, thanks a lot!

[Nashtare]

@dvdplm happy to hear your thoughts compared to your approach

[muursh]

Nice. I'm good with this

[4l0n50]

LGTM. It looks like GenerationState never needs the full GenerationInputs isn't it? So maybe it would be more "honest" to have another struct there?

[LindaGuiga]

LGTM. It looks like GenerationState never needs the full GenerationInputs isn't it? So maybe it would be more "honest" to have another struct there?

GenerationState::new needs all of the inputs to generate the initial prover inputs though. It no longer needs once all of that has been initialized, but the first time, it still needs that information.

[4l0n50]

GenerationState::new needs all of the inputs to generate the initial prover inputs though. It no longer needs once all of that has been initialized, but the first time, it still needs that information.

Yes, but I meant (though not 100% sure) that the field inputs of GenerationState doesn't need to be the full GenerationInputs.

[dvdplm]

This is awesome, much better than #81!

One word of caution though: it is going to be important to keep track of when GenerationInputs has been trimmed and when it's full-fat. In some sense the trimmed/full-fat versions are different types and it would be safer to actually have different types for them, so that it becomes impossible to misuse trim().

[LindaGuiga]

In some sense the trimmed/full-fat versions are different types and it would be safer to actually have different types for them, so that it becomes impossible to misuse trim().

So should the two different types be implemented in this PR already?

[Nashtare]

Yeah I'll take care of that tomorrow unless you want to go ahead and handle it yourself after the merge