[oss] Support refreshing the REST data token for open OSS streams

[sundapeng]

Purpose

With a REST catalog that vends data tokens, RESTTokenFileIO builds the OSS FileIO with the token it holds at that moment. A refresh only reaches FileIOs created afterwards, so a stream that is already open, such as a long read or a multipart upload, keeps signing with the old token and fails once it expires.

OSSFileIO now signs each request through RESTTokenCredentialsProvider, which reloads the table's data token from the catalog before it expires, as Iceberg's VendedCredentialsProvider does for S3. A token is reloaded an hour before it expires, or halfway through when it lives shorter; while it is still valid, one caller reloads it and the others keep using it, and a failed reload is retried after 10 seconds. Since a delegate now reloads the token as a table and a catalog user, it is shared only by callers with the same ones. fs.oss.credentials.provider can now also replace the access keys.

Tests

RESTTokenRefresherTest: 6 new cases. RESTTokenCredentialsProviderTest: 3 new cases. RESTTokenFileIOOnOSSTest: 2 new cases. RESTTokenFileIOTest: 2 new cases, 12 tests passed. OSSLoaderTest: 1 new case.

[JingsongLi]

Reviewed 93f7fc7. The REST-token/open-stream problem has clear end-to-end value, and the per-request OSS signing path is plausible. I found one production blocker in the supplier lifecycle:

[P1] Keep the supplier alive for the lifetime of an open OSS stream. CachedFileIO.close() unregisters its supplier when FILE_IO_CACHE evicts a delegate (10-hour access expiry or 1,000-entry size limit). The delegate returned by FileIO.get(oss://...) is OSSLoader.OSSPluginFileIO; PluginFileIO does not override FileIO.close(), whose default is a no-op. Thus eviction removes the supplier while the underlying OSS client and any open streams may still be live. RegisteredCredentialsProvider then silently falls back to its last credentials, and the next token expiry recreates the same mid-read failure this PR targets. The underlying uncached OSS filesystem is also not closed. Please make wrapper close reach the delegate and tie supplier removal to the actual lifetime of streams/requests, with a regression test that evicts the cache while a stream remains open and crosses a token refresh.

Validation: RegisteredCredentialsProviderTest (4), OSSLoaderTest (1), and RESTTokenFileIOTest (11) passed locally; git diff --check passed. CI run 36106203387 failed only in JDK 8/11 Core jobs because the unrelated S3FileIOTest could not pull the pinned MinIO image; its other selected jobs passed. The first local REST test attempt hit macOS sandbox denial of Mockito agent attachment; rerunning it with attachment allowed passed all 11 tests.

[sundapeng]

Thanks, good catch. Instead of fixing the supplier's lifetime I removed the registry: RESTTokenCredentialsProvider is now built from the delegate's options and reloads the table's data token from the catalog on its own, like Iceberg's VendedCredentialsProvider for S3. Nothing ties it to RESTTokenFileIO or its cache, so a stream that outlives its cache entry keeps getting fresh tokens. RESTTokenFileIOOnOSSTest evicts the cache while a stream is open, crosses a reload and checks the next read is signed with the new token. CI is green on 002bdcc.

The evicted OSS FileSystem not being closed predates this PR: RESTTokenFileIO sets file-io.allow-cache=false and PluginFileIO.close() is a no-op. Forwarding close() would close the FileSystem under open streams on eviction, for every plugin FileIO, and closing only after the last stream would need stream tracking in RESTTokenFileIO that hides VectoredReadable and misses callers of fileIO(). I'd like to handle it in a separate issue. Does that work for you?