Replace Config with configuration components

[XAMPPRocky]

Currently we have the concept of a single "monolith" config file that's shared between all services from when there was only a proxy service. In its current form I don't find it to always to be clear when something is being shared and when something isn't, so I'd like to propose that we move away from the current configuration and instead create configuration files for specific components in Quilkin, this will make it easier to isolate and share specific parts of configuration without accidentally overriding another part of configuration, which also enables us to potentially have multiple configuration providers for different components to be running at once. It will also allow for the configuration to diverge from the schema of the current Config to be potentially more user-friendly.

A couple examples of component configuration that I think we should start with, namely ones for each service, and for FilterChain configuration. To be able to share code and make the configuration of each component more unified, I think we should adopt the same schema as Kubernetes CRDs, this would allow us to reuse more code for parsing, it's a format that people are already familiar with, and it allows for these components to potentially become CRD's down the line that can be discovered using a kubernetes configuration provider.

version: quilkin.dev/v1alpha1
kind: Proxy
spec:
  filter_chain: acme.games/hello-world
  endpoints:
    - 192.168.0.1:8080
    - 192.168.0.1:8080

version: quilkin.dev/v1alpha1
kind: ControlPlane
spec:
  provider:
    kind: Agones
    config_namespace: default
    gameserver_namespace: default

version: quilkin.dev/v1alpha1
kind: Relay
spec:
  ads_port: 7800
  cpds_port: 7900

version: quilkin.dev/v1alpha1
kind: FilterChain
metadata:
     id: acme.games/hello-world
spec:
  filters:
    - name: quilkin.filters.firewall.v1alpha1.Firewall
      config:
        on_read:
          - action: ALLOW
            source: 192.168.51.0/24
            ports:
              - 10
              - 1000-7000
        on_write: 
          - action: DENY
            source: 192.168.51.0/24
            ports:
              - 7000

[XAMPPRocky]

I think these components would also allow for another service called agent, that would allow you to have all services in a config source provider, the agent could run multiple services inside a single process, and it would make the listeners dynamic. The agent could add, change and remove proxies, control planes, relays, filters, and endpoints dynamically at runtime.

Then the current subcommands would essentially just be the CLI representations of these components.

This would also be a better place for the relay client than the control plane, as it means we don't also expose aDS server, and you could replicate the same functionality of having both with the agent workflow anyway, so it would be more intuitive and secure by default.

Example agent CLI

quilkin agent agones
quilkin agent file

[markmandel]

100% yes to having different Kinds of configs. That makes total sense.

The nice thing about this, is you can still have a singular config file (and we could allow multiple -c invocations), since yaml can be separated by --- to allow for multiple documents in the same file.

The internal config object could then become a Map[Kind]/Vec of each of these Config types -- which would still also allow for /config to output the current configuration of the Quilkin instance.

Also solves my problem in #63

If we want to go with a more "Kubernetes" resource style model that people are familiar with, we should probably use name rather then id -- but it's a very small detail.