feat(gax): add ResumableUploadCallable and ResumableUploadCallSettings

[blakeli0]

Description

This PR introduces the foundational GAX Public API surface for HTTP/JSON resumable uploads.

Changes

1. ResumableUploadCallable: Transport-agnostic class with futureCall(request, payload, settings) and resumeCall(sessionUrl, payload, settings) returning ResumableUploadFuture<ResponseT>.
2. ResumableUploadFuture: Specialized ApiFuture<ResponseT> interface for active session inspection (getUploadSessionUrl()) and cancellation control.
3. ResumableUploadCallSettings: Non-generic @AutoValue configuration class with merge(other) method and chunkSize = 8MB default.
4. ResumableUploadCallSettingsTest: JUnit 5 (Jupiter) unit tests verifying default chunk boundaries and merge(other) overrides.

[gemini-code-assist]

Code Review

This pull request introduces the ResumableUploadCallSettings and ResumableUploadCallable classes to support transport-independent resumable uploads, along with associated unit tests. The review feedback suggests adding input validation to ensure chunkSize is positive and totalBytes is non-negative, as well as removing several redundant null casts in the overloaded call and futureCall methods to clean up the code.

[gemini-code-assist]

The casts (ResumableUploadCallSettings<RequestT, ResponseT>) null and (ApiCallContext) null are redundant because there is only one 4-argument overload of futureCall. Removing them simplifies the code and improves readability.

  public ApiFuture<ResponseT> futureCall(RequestT request, InputStream payload) {
    return futureCall(request, payload, null, null);
  }

[whowes]

Do we want to also provide a version that accepts something like a supplier/provider of InputStream?

An addition could probably be in a subsequent PR but I'm curious what your thinking is on the concept. IIUC, since most InputStream implementations aren't seekable/resetable (this notably includes FileInputStream) this could be useful for error recovery.

[blakeli0]

Do we want to also provide a version that accepts something like a supplier/provider of InputStream?

I think it is a good idea. But I would prefer to use the native InputStream if it already meets all the use cases.

Regarding seek-ability, FileInputStream does support skipping over bytes? It does not support resetting but I don't think we need to reset a stream either?

[whowes]

I think you're right - since we'll be buffering each chunk until complete receipt is confirmed by the server we shouldn't need to rewind or reset. So skip-ability should suffice.