header: match subdirective for response matching

[lilnasy]

• Headers can't be added by matching against response matchers #6763

Allows the header directive to specify a response matcher to apply the header operation only when the response has a certain header or status.

This PR only adds the syntax to the caddyfile parser. The runtime uses the preexisting logic implemented for the "Require" field. I went with the match name for parity with the encode directive.

There is a slight breaking concern: similar to how "defer" cannot be used a header name, a header entry where the header name is exactly "match" will no longer be considered. If there is someone using it, they will have to rename the header to "Match" (different case) instead.

Syntax example:

example.com {
	encode gzip {
		match {
			header Content-Type application/json*
		}
	}
	header Cache-Control "public, max-age=3600" {
		match {
			status 2xx
		}
	}
	file_server
}

[CLAassistant]

All committers have signed the CLA.

[mholt]

There is a slight breaking concern: similar to how "defer" cannot be used a header name, a header entry where the header name is exactly "match" will no longer be considered. If there is someone using it, they will have to rename the header to "Match" (different case) instead.

I believe this is only true when using a block; but when using the single-line syntax, there should be no conflict. IIRC.

---

Anyway, LGTM at a glance! Maybe @francislavoie could double-check but I think we can merge this.

[mholt]

j/k -- we need to fix the lint error first:

Error: modules/caddyhttp/headers/caddyfile.go:104:39: Error return value of caddyhttp.ParseNamedResponseMatcher is not checked (errcheck)
caddyhttp.ParseNamedResponseMatcher(h.NewFromNextSegment(), responseMatchers)

[lilnasy]

Thanks for the reviews! Seem like it just needs a final round tests after rebasing on top of the recent pushes.

[lilnasy]

@mholt Could you approve the workflow run?