httpcaddyfile: Add shortcut for expression matchers

[francislavoie]

This is admittedly a bit of a wacky idea... but it's super cool!!

Since #4715 we have support for calling most matchers from within a CEL expression, I think we should also have a nicer syntax for defining a matcher with an expression. Typing out the word expression to get at this functionality is not as nice as it could be.

My first thought was maybe we make an alias like expr? That is better (6 less chars to type) but it still doesn't feel great.

Then I thought of the change we semi-recently made to the parser in #4643 which allows us to detect if a token was explicitly quoted in the config. Matcher names (i.e. the module name) should never be quoted (because... why?) so I think we can make the assumption that if we see something in the place of a matcher name that is quoted, it's a CEL expression.

This reads quite naturally, because the only requirement is that you quote the CEL expression as a token, and it just works! It's true that quoting can be omitted for the long-form because of #4643, but explicitly quoting makes the shortcut possible!

Before:

@notFound expression {err.status_code} == 404
respond @notFound "Oops, not found"

After (also works with " quotes, and even multiline expressions work):

@notFound `{err.status_code} == 404`
respond @notFound "Oops, not found"

Pretty sweet! 🚀

The main concern is... are we shooting ourselves in the foot with making this assumption? Will we want to do something else with this case at some point in time? I think probably not. I think it would be pretty cool to push CEL expressions forwards as a more first-party feature rather than some "escape-hatch" feeling thing.

And this is fully backwards compatible, because this was previously impossible syntax since the first token was normally supposed to always be a matcher name.

[francislavoie]

FYI @TristonianJones 😊

[mholt]

I like it.

Can we document it as experimental? 😅 Just to see how it goes, since it kind of came out of nowhere.

But it's way cool. I can imagine this:

@goingDown vars {http.shutting_down} true
respond @goingDown 503

Turning into:

@goingDown `{http.shutting_down}`
respond @goingDown 503

being very elegant! (With the slight oddity that the placeholder looks like a literal-quoted string, but is in fact expanded.)

[francislavoie]

Yeah, we can document it as experimental on the website for now 👍