Add IAM support to APIs which support it

[tseaver]

(copied from googleapis/google-cloud-node#1192, which is funnily-enough exactly true for gcloud-python, too).

IAM is currently buried inside of our Pub/Sub code, but should be abstracted to be used with any API that supports it:

• BigQuery
• Compute
• Logging
• Pub/Sub
• Resource Manager
• Storage

[kir-titievsky]

A gentle ping on this, given that IAM is now GA: is there an IAM API coming? Any chance the Pub/Sub IAM API might be brought up to date.

[ncouture]

@kir-titievsky PR #2031 seems to be related but has not seen updates for a few months.

[tseaver]

@lukesneeringer How would you prefer that I factor out the existing google.cloud.pubsub IAM support?

• Shared bits move into a new google.clooud.iam module inside the core/ subproject?
• Shared bits move into a new iam/ subproject?

[lukesneeringer]

Good question. My instinct is that I would prefer not have an excessive number of sub-projects, and to put it in a google.cloud.iam module in core. My feeling is that if we later have six or seven projects like that, it will become hard to know what is an API and what is a shared module.

That is a loose preference though and I am happy to be persuaded otherwise.

(If this were day 1, I would have preferred it have been google.cloud.core.* namespaced.)

[tseaver]

I'm find with putting it in core/: I was just worried that we wanted to be more conservative about such changes.

[dhermes]

What about putting it all in google-auth-library-python? @jonparrott WDYT?

[theacodes]

@dhermes I'd prefer to keep code that hits any non-auth API endpoint outside of google-auth (I was actually really wary of adding IAMSigner). But I may be able to be convinced if you think it's the best place for this.

[theacodes]

gax/core seems like the right spot for this IMO.

[tseaver]

I'd vote for core at this point: the APIs of interest (pubsub, storage) don't expose any IAM-related methods over gRPC: they are REST-only. There really isn't very much code involved for the API-specific bits (mostly knowing how to formulate the request URLs, which aren't uniform).

[tseaver]

Most of the code will be in the "common" bits: schlepping the policy resource into / out of the Python object, creating various principal iDs, etc. See #3188.