feat: add generic response interceptors

[dunglas]

In proxy mode, Caddy allows intercepting and modifying responses coming from upstream servers.
This is especially useful for implementing X-Sendfile/X-Accel-Redirect-like features.

However, the current implementation of this feature is only available in proxy mode and doesn't allow to intercept and modify responses created by modules.

This makes it impossible to use features like X-Sendfile with FrankenPHP, https://github.com/mliezun/caddy-snake, and other similar potential modules (LUA module, etc).

This patch implements a generic implementation of response interceptors that behaves similarly to the reverse_proxy handle_response.

It currently does not support the copy_response and copy_response_headers subdirectives, but it should be easy to add support for these features in future Pull Requests.
It should also be possible, in the future, to replace the current reverse_proxy specific implementation with this new more generic one, but it is out of scope for this PR.

Closes dunglas/frankenphp#365. Closes dunglas/frankenphp#396.

[elghailani]

Nice feature! Thanks @dunglas !
I posted asking for help configuring similar capability in this post on caddy forum few days ago.

[mholt]

This is a cool change. I haven't thoroughly reviewed it yet but my first pass is liking where this is going. Just a couple nit picky thoughts for starters.

[mholt]

Looking good here. @francislavoie any thoughts on the Caddyfile implementation?

[francislavoie]

Since this isn't embedded within another directive, I think we don't need the finalize thing here. I think we can immediately parse the current segment as a handler and add that to the config. Then we can delete handleResponseSegments

[dunglas]

Do you have an idea of how we can do that @francislavoie? We need a httpcaddyfile.Helper to call ParseSegmentAsSubroute().

[francislavoie]

Oooh right. I'll think about it.

[mholt]

@dunglas I'll probably tag 2.8 beta 1 this week; it'd be nice to get this in 2.8 beta 1, but if not, maybe we can get it in beta 2 or the RC.

[mholt]

@dunglas Before we merge this, can we mark the exported types/methods as "EXPERIMENTAL: Subject to change or removal" (or something like that)? It sounds like there are still decisions to be made to finalize APIs to accommodate expanded functionality later, and by marking it as experimental we can at least merge it in sooner and then change it, as opposed to making painful changes later on.

[dunglas]

Sounds good to me to mark the public API as experimental. Should I update the code?

[mholt]

Yeah, if you have a chance to do that could you push a commit? I'm wrapping up a few things here.

[dunglas]

@mholt done (the public type was already marked as experimental).

[mholt]

Ah, okay thanks. I was mobile this weekend so thanks for double-checking.