Support of Go 1.7 http.Request's Context

[zirkome]

This PR enable to use the Go 1.7 http.Request Context.

This feature is disable by default but can be enabled through the request_context parameter.

The usefulness of this is that we can now add middlewares and add metadata before calling gRPC services. I'm also using that as part of a distributed system (e.g. Zipkin) and need to pass metadata between HTTP and gRPC which can only be done through the same per-request context.Context.

If you enable the option there will be breaking changes.

[tmc]

@kokaz thank you for your contribution -- can you document said breaking changes next to the parameter description in README.md?

[zirkome]

@tmc I updated the README.md is that OK?

[zirkome]

ping @tmc :)

[tmc]

I'm uncomfortable with the amount of duplication involved here but really do like the idea.

What do you think about maintaining the surface api but preferring req.Context in Register{{$svc.GetName}}Handle?

[tmc]

I'd like to keep the number of knobs low for simplicity's sake -- another option on the table would be dropping go<1.7 support. (I don't have great sense of the distribution of active go versions using this package).

[zirkome]

@tmc I don't like this amount of duplication too, but that was the only solution that came to my mind to avoid direct breaking changes. I like the idea of dropping support for versions < go1.7 but like you said it might be a problem if the distribution of < go1.7 is too large. I don't know how we can deal with this. If we're going to support for versions > go1.7 I'd be happy to redo my PR to take this in account.

[zirkome]

@tmc A thought that I had was to use build tags in order to prefer one API over the other but this involves moving templates in another files (e.g. template_pre17.go and template_go17.go). The gRPC-Go transport package has build tags for pre1.6, 1.6 and 1.7 (https://github.com/grpc/grpc-go/tree/master/transport)

[hatchan]

@kokaz The build tags need to be added to the generated code, right? As it doesn't matter which Go version was used to compile this binary.

The generated code could generate two files and then have build tags applied. But the biggest issue is the API signature of the generated code is different for both versions. Whereas the older on expects a context, the new code does not.

[zirkome]

@hatchan This PR changed the signature of Register{{$svc.GetName}}Handle but in fact the best to do that would have be to just ignore the context with _. It will be part of the next iteration of this PR after we have a final decision on all that :)

[zirkome]

@tmc what do you think?

[tmc]

I think not changing the signature is the way to go there.

This will mean req.Context() will be a "context" not an "x/net/context" which has some less-than-friendly implications until upstream drops 1.6 support or we get aliasing.

It seems like the simplest thing would to just swap out that one particular line depending on the flag's presence vs wading into build tag complexity -- i think we can assume folks that opt into this flag are responsible adults that know what they're doing.

[zirkome]

@tmc I changed the signature so that it won't break anything. For the std context vs x/net/context this won't break anything as it's just an interface and that x/net/context wraps around the std package when building with Go1.7.

Btw, the build seems to fail because of genswagger lint issue

[tmc]

@kokaz what do you think about ditching the extra template and just doing the logic in a conditional in one template?

[tmc]

@kokaz we discussed offline but just to drive the conversation forward, this is the sort of approach I had in mind: master...tmc:request_context

[zirkome]

@tmc This remove a lot of the duplicate code I did, so I'm in favor to close this PR and use your work

[tmc]

@kokaz great, opened another PR, let's move discussion there.