httpcaddyfile: Add shorthands for parameterized placeholders

[francislavoie]

Adds the following new placeholder shorthands to the Caddyfile (plus one non-* placeholder):

{port}      ->  {http.request.port}
{query.*}   ->  {http.request.uri.query.*}
{labels.*}  ->  {http.request.host.labels.*}
{header.*}  ->  {http.request.header.*}
{path.*}    ->  {http.request.uri.path.*}
{re.*.*}    ->  {http.regexp.*.*}

These are quite commonly used placeholders. Because they're relatively long, it's hard to remember the exact syntax on the fly, requiring frequent referencing of the docs to verify.

Currently I implemented this via just a quick prefix replacement, it's unlikely users would use these string patterns on their own. Probably the most concerning would be {r. because it's such a short sequence.

I chose the very short {r.*.*} as the syntax for the regexp placeholder, because when users provide a name argument, it's pretty obvious what r is referencing, since the name will be associated with a path_regexp or header_regexp matcher. It's easy to trace in the Caddyfile.

Edit: Switched to {re.*.*} for some added clarity.

As an improvement to this, in second iteration I think we could implement this via regexp replacements instead, it would probably be safer as well because we'd verify the final } is actually present. Just wanted to get out a quick proof of concept first.

Edit: Done, implemented using regexp. Pretty easy.

[mholt]

This was simpler than I thought it'd be!

For the record, it is also possible to use the existing list above for pretty much all these replacements, i.e.: {"query.", "{http.request.uri.query." without using regexp, but as we discussed on Slack, performance doesn't really matter here, and with the regex we get the benefit of ensuring there's a closing curly brace } rather than assuming. Probably not a big deal; if we wanted to simplify the code, that's one easy way to do it. (ref. this commit: 09075d8)

I would suggest that the regexp be compiled only once though, rather than in a loop.

[mholt]

@francislavoie When you have a chance could you help with the merge conflict? I'll do another review then.

[francislavoie]

Rebased! Btw, easier to review with whitespace changes hidden.

[mholt]

Thanks, looks good!

My only remaining question is about the use of r. I like short, but I almost never see r used to mean regular expression. I usually see regex or regexp or at least re.

What do you think of re?

[francislavoie]

re is okay 👍 does make me think of like Re: (regarding) in emails, but I don't find it particularly unclear.

[mholt]

Great, LGTM! Thanks Francis.