feat(refactor) - code refactoring and generalization

[ctrlc03]

• Add admin only endpoint to add a new circuit config (zkey and wasm)
• Add endpoint to generate multiple proofs at once
• Refactor single proof generation endpoint to spawn a new go routines safely
• Add DB support (postgres) to store data to a DB
• Add endpoint to get the registered circuits details
• Add endpoint to get multiple proofs results for one circuit
• Add endpoint to get multiple proofs results for multiple circuits
• Add endpoint to dump all available proofs from the DB
• Generalize API to support any circuit
• Add TLS support
• Add new demo cli commands

[samajammin]

What's the status on this PR? @gurrpi have you reviewed?

[baumstern]

What's the status on this PR? @gurrpi have you reviewed?

Beginning a review now, noting the PR's extensive scope and the need for a design evaluation.

[baumstern]

@ctrlc03 thank you for your patience. I'm now beginning a review of this PR. A few high-level concerns before code review:

1. Size: The PR is large, making it difficult for an effective review. Could it be broken down into smaller, more manageable parts?
2. Design Alignment: The PR suggests a broader generalization, moving away from our current MACI-centric focus. A separate design discussion is needed to align it with our project's existing goals and documentation (PO doc, Design doc.
   2.1. Project Focus: We should clarify if we aim to create a library that can be used broadly by zk developers, or if our focus is on building services specifically for MACI application developers.
3. Isolated Features: Elements like the zkey downloading feature could be isolated and submitted as separate PRs. This could also address our current issue with the Docker image size.
4. Use-Cases and Implementation Strategy: Implementation strategies will differ depending on use-cases and request patterns (e.g., I/O-intensive vs. computation-intensive), making complete generalization challenging.

Please clarify these before we proceed.