feat: Parameterize the fallback handler to httprule.Server

[boblail]

Allow clients to define their own behavior in place of http.NotFound if none of the httpRuleTemplates were matched

[camh-]

@boblail

I'm happy to merge something like this, but I'm not sure it's right as is:

1. I don't think that the user of httprule.Server should be responsible for passing in a NotFound handler. The NotFound behaviour should stay the same with an optional ability to override that behaviour - i.e. provide the next handler. If this is not provided, then the current NotFound behaviour should continue.

2. The NewServer() function has been accumulating arguments. Given what I said above, this would be another optional argument. Perhaps it is time for this to take options as the serve package does for serve.Server.

While this is still a v0 module, I would still try to not break existing users. So to do the option arguments, I am considering renaming httprule.Server to httprule.Handler (since it really is a handler, not a server). Then we could alias Server to Handler, have MakeHandler() take the option arguments, and leave MakeServer as is. Your new use case would need to switch to MakeHandler() and provide the option arguments.

How does this sound? I'm happy to knock this together if you like.

[camh-]

@boblail Also, would you mind giving a quick run down of your use case? That is, include the "why" in the commit message / PR description? I think the "why" is always important as it helps to understand how to review as well as providing context when looking at the history years later.

[camh-]

I've pushed a couple of commits to the http-default-handler branch: https://github.com/foxygoat/jig/commits/http-default-handler - the first refactors the Server/Handler as describe above and the second adds an optional "default" handler. Let me know what you think of this approach.

[boblail]

@camh-,

Everything you said sounds reasonable to me!

• Functional options (especially so that http.NotFoundHandler() can be the default) feel better than adding another positional argument. 💯
• Renaming Server to Handler also better expresses its role 👍
• I pulled https://github.com/foxygoat/jig/commits/http-default-handler into our project and it works well! 🚀

Here's our why:

We have a fake server that serves both gRPC and REST fakes.

We considered doing something like this:

jigServer.SetHTTPHandler(handlerThatRecognizesRestRequests{next: httpruleHandler})

but we really want any incoming request whose path looks like a gRPC-Web request to be handled by the httprule handler.

So — to our best understanding now — the logic we need is something like:

1. If the incoming request is HTTP/2 and application/grpc, handle it as gRPC (https://github.com/foxygoat/jig/blob/master/serve/server.go#L109 ✅)
2. If the incoming request's path looks like a gRPC-Web request, let httprule handle it
3. Otherwise, assume it's a REST request, and handle it ourselves

[camh-]

@boblail I won't be able to update your branch, since it's on a fork, so I'll raise a new PR with the changes from that branch.

[camh-]

I've raised #49 - I'll get @juliaogris to review it so we can merge it.

[camh-]

#49 has been merged now. Sorry for the delay.

[boblail]

@camh-, this is great! Thanks for working with me on this!