Ensure Context arg is the same as request Context

[bmarini]

This is a step towards deprecating the context argument in favor of using request.Context() directly.

[danilotsr]

so this is overriding r.Context with the argument ctx, so would it be possible to loss data configured in the previous r.Context instance? What if the server made r.Context cancelable for instance?

[bmarini]

Hmm, that's a good point. The assumption is that at all times the ctx passed into ServeHTTPContext will be the same object as r.Context(). They start off as the same object in the background middleware, and with this change, they would stay the same object.

[bmarini]

With this change, we could support using our httpx middleware with a regular http.Handler such as mux.Router like this #100

And eventually deprecate the ServeHTTPContext interface. I'm just playing with some ideas here though.

[danilotsr]

I agree with the direction here, however I'm concerned this may mask non-intended behavior where there might be two different Context objects here. If httpx handlers can rely on the request's context, then they could simply ignore the ctx arg here during this transition period, no?

[bmarini]

I think either way is a risk. An app can have custom middleware that relies on modifying the context passed in or the request context. In our case it is almost certainly relying on the context passed in.

[danilotsr]

Ok, let's get this going so that we can move away from passing in a context.Context argument sooner rather than later.