Remove dependency to common ConstraintSystem in the backend

[ed255]

After the frontend-backend split, both the backend and frontend were using the same ConstraintSystem internally. This has the following implication

• The shared ConstraintSystem uses Expressions that can have selectors, but the backend shouldn't have any code related to selectors

This PR does:

• Create a generic Expression type in middleware that can be easily customized for the backend and frontend needs. The point of this is to reuse some code. Then we have the following configurations:
  • Expression without selectors, without query indices: the one used by the ConstraintSystemMid, which is part of the API to pass a compiled circuit to the backend.
  • Expression without selectors, with query indices: the one used by the ConstraintSystemBack. This is an internal type of the backend and is generated during the setup. All the queries in expressions are indexed so that evaluations can be done fast.
  • NOT DONE: Expression with selectors, without query indices: this would be used by ConstraintSystem in the frontend. This would be a frontend type and would be used as part of the API to build the polynomial identities, and also would be used by the MockProver to evaluate the the circuit on a given witness. This is not done in this PR: I don't know if I should do this because it's a significant breaking change. Here are the pros and cons:
    • Pros: Code reuse (notice how the new Expression in middleware copies a lot of code of the Expression in common)
    • Cons: Breaks the frontend API because now the Expression enum type is different
• BREAKING: Remove the dependency of the Circuit trait in the backend. This changes the serialization and deserialization format of keys. Previously this serialization was implemented as a generic method using the Circuit trait; it would configure the circuit to extract its configuration, and from it read the keys. Now it receives a ConstraintSystemBackend (which is the output of the configuration, or also part of the output of circuit compilation).
• Rename permutation::ArgumentV2 to permutation::ArgumentMid
• Rename ConstraintSystemV2Backend to ConstraintSystemMid
• Rename GateV2Backend to GateMid
• Rename lookup::ArgumentV2 to lookup::ArgumentMid
• Rename shuffle::ArgumentV2 to shuffle::ArgumentMid
• Move the following from halo2_common to halo_frontend (as they are no longer used in halo_backend):
  • Error
  • Expression
  • sealed::Phase
  • Circuit
  • Chip
  • layouter
  • Selector
  • {Advice,Fixed,Instance}Query
  • TableColumn
  • Assignment
  • Gate
  • ConstraintSystem
  • And many smaller types used as auxiliary types by some of the previous types/functions
• Add legacy wrappers to read/write setup keys that work with the Circuit trait: pk_read and vk_read in halo2_proofs
• Split the implementation of converting selectors to fixed columns into two parts:
  • One part just converts the ConstraintSystem, transforming the selectors into fixed columns (compressed and direct versions)
  • The other part transforms the assignments of selector columns into assignments of fixed columns based on the mappings calculated in part one.
  • Add a flag in ConstraintSystem that marks when the transformation of selectors to fixed has been done, so that it panics if the transformation is attempted a second time.

Related issue: #266

NOTE: I'm not marking as breaking the changes that affect the frontend-backend split, only the changes that affect the legacy API, because we still haven't made any release with the frontend-backend split.

Blocked by #289

[adria0]

Did a quick review, added some comments.

[duguorong009]

Great work! LGTM! 🚀

I have just one comment.
I think that the remaining modules(helpers, multicore, plonk) of halo2_common can be moved to halo2_backend. right? @ed255
Maybe, it could be better to move all of those in this PR. And remove halo2_common.

[CPerezz]

Awesome work!!!!!

[ed255]

Great work! LGTM! 🚀

I have just one comment. I think that the remaining modules(helpers, multicore, plonk) of halo2_common can be moved to halo2_backend. right? @ed255 Maybe, it could be better to move all of those in this PR. And remove halo2_common.

I didn't check in detail but I had the impression that the remaining work regarding halo2_common was small. I would prefer doing that work in a future PR just because this one touches many lines and it would be great to merge it as soon as possible to allow other work to make progress without facing conflicts.