Make Expression copiable using singleton arena

[adria0]

NOTE: Relevant files to review are halo2_frontend/src/plonk/circuit/{expession.rs, arena.rs}

This an experiment about making expression copiable. To implement this we go with this strategy:

• Create a type called ExprRef<F> that contains the index (usize) of an expression stored in an specific arena.
• Modify the struct Expression to use ExprRef instead the a recursive Expression that makes it non-copiable.
• In order to access to the Expression arenas, we create a new trait that allows to access to the expression arena for an specific field, called FieldFront. Mainly we change all frontend from Field to FieldFront, making arena accessible everywhere.

pub trait FieldFront: Field {
    // Since base trait is not referenciable, we need a way to access it.
    // This is necessary to provide a way to transform fields from/to backend.
    type Field: Field;
    fn into_field(self) -> Self::Field;
    fn into_fieldfront(f: Self::Field) -> Self;

    // Allocate a new expression
    fn alloc(expr: Expression<Self>) -> ExprRef<Self>;

    // Get an expression
    fn get(ref_: &ExprRef<Self>) -> Expression<Self>;

    // Replace an expression
    fn replace(expr: Expression<Self>, ref_: &ExprRef<Self>);
}

This means:

• Library users needs to change <Field> for <FieldFront> and automatically all their Expressions are automatically copiable. This is thread-safe.
• Arenas are not dropped and lives until the whole program is finished.
• Arenas are field-especific and cannot be defined outside the halo2_crate ( this is due that is not possible to implement external traits on external types ).

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 81.97065% with 86 lines in your changes missing coverage. Please review.

Project coverage is 81.81%. Comparing base (32599e8) to head (c8c7ff9).
Report is 1 commits behind head on main.

Files	Patch %	Lines
halo2_frontend/src/plonk/circuit/expression.rs	69.11%	63 Missing ⚠️
halo2_frontend/src/dev/failure.rs	12.50%	7 Missing ⚠️
halo2_frontend/src/plonk/circuit.rs	0.00%	4 Missing ⚠️
halo2_proofs/src/plonk/prover.rs	98.05%	4 Missing ⚠️
halo2_frontend/src/dev/tfp.rs	0.00%	3 Missing ⚠️
halo2_proofs/src/plonk.rs	50.00%	2 Missing ⚠️
halo2_frontend/src/dev/failure/emitter.rs	0.00%	1 Missing ⚠️
halo2_frontend/src/dev/gates.rs	0.00%	1 Missing ⚠️
...o2_frontend/src/plonk/circuit/constraint_system.rs	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #354      +/-   ##
==========================================
- Coverage   82.09%   81.81%   -0.29%     
==========================================
  Files          83       83              
  Lines       17228    17452     +224     
==========================================
+ Hits        14143    14278     +135     
- Misses       3085     3174      +89     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[davidnevadoc]

I believe this may introduce an issue in the use of generic fields:
A user may want to import a ff::Field from a foreign library ( halo2curves for example), he won't be able to implement FieldFront for this type and therefore, won't be able to plug it in the halo2-front.

Would it be possible to make a generic implementation so all Fields automatically implement FieldFront?

[adria0]

Maybe, but there's currently another limitation in the current approach:

Arenas are field-especific and cannot be defined outside the halo2_crate ( this is due that is not possible to implement external traits on external types ).

So, users has to fork the library and add its own type inside.

It needs another approach if we want to be able to integrate foreign fields, yes.

[davidnevadoc]

I think there is no workaround this issue, this is a deal-breaker :/