Support idempotency token for Storage client

The GCS API supports (or soon will support) an idempotency token header. The header allows GCS to detect if a request is a duplicate, and returns the same value for duplicate requests.

To implement this we need to:

• Create the unique id in the RetryClient
• The decorators below RetryClient need to accept a new "context" field on each function
• The gRPC and REST-based implementations need to consume this field and send it to the service as a header.

It is time to split the RawClient stack in two, like we do for all the other libraries. The *Connection stack will be used for mocks and to implement the retry loop. The typical function will look like so:

  virtual StatusOr<BucketMetadata> GetBucketMetadata(
      GetBucketMetadataRequest const& request) = 0;

The *Stub will implement logging, tracing, and actually sending the data to the service, the typical function will look like so:

  virtual StatusOr<BucketMetadata> GetBucketMetadata(
      rest_internal::RestContext& context,
      Options const& options,
      GetBucketMetadataRequest const& request) = 0;

Note how the options are passed explicitly and not tunneled via CurrentOptions. Also note that the "context" object is REST-based. We can change both over time, as the classes in the *Stub hierarchy are not needed for mocking.

Java implemented this in:

https://github.com/googleapis/java-storage/pull/2027

Internally, the design doc is go/gcs-client-idem-token

首先跟踪 issue 中提到的 RetryClient、RawClient 以及 gRPC 和 REST 实现。检查 *Connection 和 *Stub stack 是如何分离的，包括 context 和显式 Options 的流转。完成的标准是创建 token，通过两个实现进行传播，并作为服务标头发送，同时保留 mocking 和 retry 行为。