feat: add x-goog-api-client headers for retry metrics

[ddelgrosso1]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

[danielbankhead]

I didn't catch this line during our pairing, but I believe this may break package.json#files for consumers (via npm i @google-cloud/storage) as build/package.json wouldn't be included [npm docs].

We currently use this pattern for including package.json (a little messy):

nodejs-storage/src/storage.ts

Lines 617 to 625 in cbe2590

	let packageJson: ReturnType<JSON['parse']> = {};
	try {
	// if requiring from 'build' (default)
	packageJson = require('../../package.json');
	} catch (e) {
	// if requiring directly from TypeScript context
	packageJson = require('../package.json');
	}

We have a few options:

• Perhaps we can add build/package.json to package.json#files. Drawback: some tooling may believe build in itself is a separate package (as package.json) and may misbehave.
• We can use the pattern found in src/storage. Drawback: messy-looking.

CC: @bcoe - as I'm working on an easy package.json import proposal for Node.js.

[danielbankhead]

The gl-node/... and gccl/... portions may not match for tagged semver preview/beta releases.

Here's a suggestion:

Suggested change

	/^gl-node\/[0-9]+\.[0-9]+\.[-.\w]+ gccl\/[0-9]+\.[0-9]+\.[-.\w]+ gccl-invocation-id\/[\w]{8}-[\w]{4}-[\w]{4}-[\w]{4}-[\w]{12}$/;
	/^gl-node\/(?<nodeVersion>[^W]+) gccl\/(?<gccl>[^W]+) gccl-invocation-id\/(?<gcclInvocationId>[^W]+)$/

Which will allow easy access to named groups for testing:

const match = X_GOOG_API_HEADER_REGEX.exec(...);

assert(match);

// match.groups.nodeVersion
// match.groups.gccl
// match.groups.gcclInvocationId

[danielbankhead]

^this suggestion is optional

[tritone]

Just to clarify-- I spoke with @frankyn and he mentioned that each request in a resumable upload should have its own invocation id (unless it is a retry of a request that failed). Is that reflective of what's happening here?

(Looks like it is from the test cases, but wanted to double check)

[ddelgrosso1]

Correct, that is what is happening here. The invocation ID is only changed after a successful response. If a failure case is hit the same ID will be used on the retry. Each request (create a URI, send a chunk, etc...) all utilize a new ID.