Add client_info to constructors for manual clients

[tswast]

The client_info constructor argument is the standard argument for changing user agent headers in GAPIC clients. Adding a user_agent prefix identifying an app or tool is required for many partners who use Google APIs.

Handwritten clients should provide a similar client_info argument to the client constructor. See how this was done in BigQuery at #7806.

Clients that need client_info:

• BigQuery (Add client_info to BigQuery constructor for user-amenable user agent headers #7806)
• Bigtable (Bigtable: add 'client_info' support to client. #7876)
• Datastore
• DNS (DNS: Add 'client_info' support to client / connection. #7869)
• Error Reporting (Error reporting: add 'client_info' support to Client. #7903)
• Firestore (and Firestore Beta) (Firestore: add client_info support to V1 client. #7877, V1 only, see below)
• Logging (Logging: add client_info support to client / connection. #7874, Logging: plumb 'Client._client_info' through to GAPIC API wrapper. #7901)
• Pub/Sub (Publisher, Subscriber) (done via **kwargs)
• Resource Manager (Resource Manager: Add 'client_info' support to client / connection. #7870)
• Runtime Config (Runtime Config: add client_info support to client / connection. #7871)
• Spanner - Note: Spanner has a user_agent argument already, but it's currently a no-op. Should mark that as deprecated. (Spanner: add client_info support to client. #7878)
• Storage (Storage: add client_info support to client / connection. #7872)
• Trace and Trace V1 (Trace: add client_info support to clients. #7899)
• Translate (Translate: add client_info support to client / connection. #7873, no GRPC version needed, because v3beta1 is pure-autogen)

I've heard requests for this feature in the Storage client, so I'd prioritize that one above the others, but we do need this feature across all clients.

[tseaver]

My current plan:

• Hoist @tswast's work from Add client_info to BigQuery constructor for user-amenable user agent headers #7806 up into the google.cloud._http.JSONConnection base class. (Core, BigQuery: refactor 'client_info' support. #7849)
• Deprecate the USER_AGENT and _EXTRA_HEADERS class-scope constants in that class, in favor of new instance properties, user_agent / extra_headers. Replace the deprecated class-scope names with properties which emit warnings when assigned. (Core, BigQuery: refactor 'client_info' support. #7849)
• Document the client_info parameter in all classes which derive from JSONConnection.
• Add client_info to the constructor of those clients which use connections based on JSONConnection, and pass it through to the connections (storage, dns, logging, resource_manager, runtimeconnection, translate).
• For clients which do not use JSONConnection, add client_info to their constructors and forward it to their GAPIC clients.

[tseaver]

@tswast One thing I've noticed while deprecating the _EXTRA_HEADERS variable: you bend over backwards to allow self._EXTRA_HEADERS["foo"] = "bar". I think I'd rather avoid supporting that, and instead just allow assignment to it. WDYT?

[tswast]

I think I'd rather avoid supporting that, and instead just allow assignment to it. WDYT?

Seems reasonable, since we're making a new property name now. I bent over backwards because we had some tests that did key assignment and I wanted to maintain compatibility.

[tseaver]

@tswast I just realized that since we've hoisted the logic for adding the X-Goog-API-Client header into the base class, we can avoid jamming it into the extra_headers return value, which makes allowing assignment into it simple.

[tseaver]

@tswast I think we should leave this feature out of the firestore_v1beta1 client object: the Firestore team really doesn't want to encourage new users for that version of the API.

[tswast]

Thanks @tseaver ! The REST clients LGTM. A few questions on the gapic clients.

[tswast]

🎉 Thanks! 🎉

Are we following-up with a bunch of releases next (or at least for api_core)?