Oniongroove prototype - second iteration

Description

• This iteration goal: support both C Tor and Arti as backends.
• Next iteration goal: feature-parity with Onionspray for what's needed for Project 145 and for the C Tor backend; migration procedure.

Tasks

• Use Arti from a Debian package (ref. tpo/core/arti!2323 (merged))?
• Update the specification to be implementation-agnostic:
  • Consider writing a separate spec for the implementation.
  • Formal data structure on the feature set for each backend.
  • Config validation.
  • Change detection (backend or option change).
  • Change validation.
  • Config compilation.
  • Arti to C Tor is unlikely, so maybe throw an error in this case.
  • Define how to handle key material.
• Update the data model and configuration format accordingly.
• Split architecture into implementors, and don't rely on specific choices:
  • Onion Services protocol implementations:
    • Arti.
    • Consider also to support C Tor (can be helpful for migrating/adopting Oniongroove in stages).
  • Rewriting proxy implementations:
    • OpenResty
    • NGINX with extra packages maybe could be another.
    • Envoy.
    • Sōzu.
    • pingora.
  • Deployment implentations: many flavors might be supported (but only one per provider at this point):
    • Container-based:
      • Docker Compose.
      • Podman Compose. This is the easiest to implement right now, and it's almost done.
      • Nomad.
      • Kubernetes.
    • Non-container based:
      • Ansible.
      • Puppet.
      • Terraform.
• Features:
  • Always fetch upstream content over the internet through HTTPS.
  • HTTP2 support.
  • Caching support.
  • TLS improvements (updated cipher suite). Reference: tpo/tpa/team#32351.
  • Allow specifying Vanguards mode (lite or full).
  • Support for non-HTTPS onionsites.
• Evaluation:
  • Arti: send feedback/open tickets from the Oniongroove prototype experience. e etc).
  • Performance, stability and usage tests.
  • Goal to consider in the design: dynamically set parameters based on system load, including burst rates. The "groove" is not just about descriptor-based load balancing, but balancing load with many parameters.
  • Design a certificate (including ACME) manager.
• Management:
  • Plan the next iteration.