Remove TransformsFromConfig trait

[rukai]

Understanding how config works is easier without the extra layer of indirection.

[conorbros]

This refactor makes sense to me. Nice one

[benbromhead]

This makes sense... though would it be better to actually just have the config as a dyn trait object and remove the enum? I think I've looked at this before and can't remember if it makes serialization of the config struct hard?

Config is just done at startup... so no perf concerns

[rukai]

I thought you couldnt serialize trait objects.
But looking into it I found this: https://github.com/dtolnay/typetag
So ill have to investigate to see if that way is better.

[rukai]

I got a 95% solution for a config trait.
It compiles and works: rukai@9c0b560

However among various minor complications such as extra complexity + compile times the main problem comes down to a limitation in deserialization with typetag.
There is no way to express a Config struct without any fields like Loopback.
The only way to express that would be via something like : Loopback: {} or Loopback: ~
Which is really unintuitive.

So because of this lets stick with this PR and abandon using a trait.
We might have important reasons for wanting a trait in the future and we can try again then.

[benbromhead]

It's a bit disapointing that typetag makes the UX worse as it looked like a simple solution to "registering" config objects.

This largely looks good to me.

Can you update the docs. cargo doc throws some warnings for refs to the now non-existent config trait. The docs folder might also need updating (docs.shotover.io)

[rukai]

cargo doc changes should be good.
I didnt see anything documenting writing transform config code in the docs/ folder.

[github-actions]

1 benchmarks reported regressed performance. Please check the benchmark workflow logs for details: https://github.com/shotover/shotover-proxy/actions/runs/1366148068