Determine how to handle before_request for gRPC

[theacodes]

I discovered that I did something totally wrong when I implemented our grpc transport.

All of our HTTP transports call credentials.before_request to get the authorization header populated (here). However, the gRPC transport instead calls credentials.refresh directly and constructs the header itself (here).

I think the gRPC transport needs to do the same as the others, but that's where it gets tricky. before_request takes 4 arguments request, method, url, request_headers. gRPC provides our auth plugin with a context that looks like AuthMetadataContext(service_url='https://pubsub.googleapis.com/google.pubsub.v1.Publisher', method_name='ListTopics'). Does it make sense to call before_request(http_request, context.method_name, context.service_url, headers) even though context.method_name is not an HTTP method? It it okay to overload the term method for different transports?

@dhermes @lukesneeringer thoughts?

[dhermes]

I never understood why we cared that there was a gRPC "transport" since it can't do much/any of the handshakes over the wire. So in that light, why do we care about giving it a novel interface?

[theacodes]

@dhermes I'm not sure what you mean. What's the alternative?

[dhermes]

Just a module with gRPC helpers (which is essentially what it is already).

[theacodes]

What would you remove from the current module? Or do you just not like that it's in google.auth.transports.

At any rate, gRPC needs to support all of our existing credentials and needs to interact with them properly, so the gRPC auth metadata plugin needs to call before_request just like everything else.

[theacodes]

This might be easier to explain in code #116

The key thing I'm stuck on here is look at the updated docstring for before_request.