caddyfile: Populate regexp matcher names by default

[francislavoie]

This is something I've been mulling over for months, I was trying to think of the right solution to solve this, and I think I finally just realized "duh, just add a context map to the dispenser".

The idea is that often users might define a named matcher with a regexp like this:

@oldposts path_regexp oldposts ^/post/(.*)$
redir @oldposts /posts/{re.oldposts.1}

We wrote oldposts a total of four times 😬 What if we instead we could omit having to name the regexp, when we've already named the named matcher? With this PR, now this works:

@oldposts path_regexp ^/post/(.*)$
redir @oldposts /posts/{re.oldposts.1}

Anyway, this is kinda complementary to #6113 but totally independent. With that one, this is possible, by not even using the matcher name at all:

@oldposts path_regexp ^/post/(.*)$
redir @oldposts /posts/{re.1}

Which is fine for simple cases where the regexp is used immediate after matching and there's no risk of another regexp matcher clobbering it.

Worth noting, because of how CEL matchers are compiled & provisioned at runtime, and not at Caddyfile-adapt time, this feature doesn't work for passing names into expression matchers right now. It might be possible to add the matcher name to the expression matcher's JSON as well, so that at runtime it can add it to the context when provisioning. Not sure if that's worth doing yet, but I might take a crack at it just for completion's sake.

[francislavoie]

I implemented it for the expression matchers as well. It's kinda gnarly though:

• MatchExpression has custom JSON marshaling. I don't know why we did that. But anyway if we want to pass through the Name, we need to marshal it as a whole object and not just the expression string. So I changed it accordingly. Ran into issues with infinite loops/stack overflows because lol JSON marshal/unmarshal is recursive, so we need to use separate types as the target to cancel the recursion. Thankfully, this is fully backwards compatible with old JSON configs (obviously Caddyfiles will adapt differently but that's fine).
• Added a ctx.WithValue() helper to copy the caddy.Context, because the stdlib context.WithValue() returns a ctx.Context but we need a caddy.Context and type asserting gave me an error saying "it's not a caddy.Context, it's a ctx.valueCtx 😭
• Tests broke because we're using context during expression provisioning, so I had to fix it to use a proper context. No biggie, just copying how we did it in other tests.

[mholt]

Thanks for all this work, wow.

I do have concerns that it feels quite complex (code logic) just to save 1 token (or possibly 2 tokens) in the config.

I also wonder what if the matcher has multiple regexes? (I think that's possible, IIRC. Maybe not. Haven't looked lol)

[francislavoie]

I also wonder what if the matcher has multiple regexes?

It's only possible if you use header_regexp and path_regexp in the same matcher set, can't have multiple of the same. But obviously a CEL matcher can have many of each.

At that point, the user is expected to use a name to disambiguate them.

[mholt]

Nice work -- thank you Francis for improving the Caddyfile!