feat(caddy): add a WebSockets handler that connects to Shadowsocks handler

[sbruens]

This PR enables Shadowsocks-over-WebSockets functionality in the Caddy server, allowing clients to connect to Shadowsocks servers via WebSockets. This is achieved by introducing three new modules:

1. Named Connection Handlers: These reusable handlers can be shared by different applications and are configured within the Outline app.

2. WebSocket-to-Outline Handler: An HTTP app handler which bridges WebSocket requests to a designated named connection handler, enabling Shadowsocks connections over WebSockets.

3. Layer4 Outline Handler: A layer 4 handler which bridges TCP/UDP connections to a designated named connection handler.

Example Configuration:

This example demonstrates how to configure a Shadowsocks handler with access keys and utilize it for both WebSocket and TCP connections:

  outline:
    ...
    connection_handlers:
    - name: ss1
      handle:
        handler: shadowsocks
        keys:
        - id: user-0
          cipher: chacha20-ietf-poly1305
          secret: Secret0

apps:
  http:
    servers:
      '1':
        listen:
        - ":8000"
        routes:
        - match:
          - path:
            - "/tcp"
          handle:
          - handler: websocket2layer4
            type: stream
            connection_handler: ss1
  layer4:
    servers:
      '1':
        listen:
        - tcp/[::]:9000
        routes:
        - handle:
          - handler: outline
            connection_handler: ss1

[fortuna]

Why do you need both loggers?

[sbruens]

Because caddy's WrapConnection() expects a zap logger, not an slog logger: https://github.com/mholt/caddy-l4/blob/87e3e5e2c7f986b34c0df373a5799670d7b8ca03/layer4/connection.go#L33. We use it below in the ServeHTTP() function, so we have to reference both.

[sbruens]

Because caddy's WrapConnection() expects a zap logger, not an slog logger: https://github.com/mholt/caddy-l4/blob/87e3e5e2c7f986b34c0df373a5799670d7b8ca03/layer4/connection.go#L33. We use it below in the ServeHTTP() function, so we have to reference both.

[fortuna]

I'm not a fan of not knowing our types. This makes our code fragile.
At a minimum, we need to document when to expect an IP and when to expect an addr:port.
But the http documentation says this is a host:port. Why do you need to parse as IP?

[sbruens]

The documentation also states the RemoteAddr has no defined format. The http server sets it to host:port, but the forwarded proxy headers are usually just an IP. The gorilla library sets the header IP value in RemoteAddr: https://github.com/gorilla/handlers/blob/9c61bd81e701cf500437e1b516b675cdd3b73ca7/proxy_headers.go#L46C13-L46C18. If we want to use that we should support both. I can add a comment though.

[fortuna]

Why do you need this?

[sbruens]

The layer4 handler we pass this to expects a *layer4.Connection. https://github.com/mholt/caddy-l4/blob/87e3e5e2c7f986b34c0df373a5799670d7b8ca03/layer4/connection.go#L33