ref(vortex-io): unify cloud object storage api

[m7kss1]

Summary

Cloud object store construction was duplicated across vortex-jni and vortex-duckdb,
each with hand-rolled per-scheme builders (AmazonS3Builder, MicrosoftAzureBuilder,
GoogleCloudStorageBuilder), hardcoded scheme lists, and inconsistent credential handling

Introduce FileLocation in vortex-io as the single resolution point for any
URL or path string - no manual builder code required

// Handles local paths, file://, s3://, gs://, az://, https:// - anything object_store supports
// Use credentials from env (AWS_ACCESS_KEY_ID etc.)
match FileLocation::resolve(url)? {
    FileLocation::Local(path) => { /* open with async_fs */ }
    FileLocation::Remote { store, path } => { /* open with ObjectStore */ }
}

// Explicit credentials override env (e.g. per-connection props passed)
// props example: {"access_key_id": "XXX", "secret_access_key": XXX", "region": "eu-west-X"}
FileLocation::resolve_with_props(url, java_properties.iter()
    .map(|(k, v)| (k.as_str(), v.as_str())))?

By the way, now object store works out of the box in CLI :

$ AWS_REGION=us-east-1 vx query s3://bucket/hits.vortex --sql "select count(*) from hits"
$ vx tree gs://bucket/hits.vortex

Closes: #000

Testing

AI disclosure: XXX

[m7kss1]

note: verified only on s3-compatible storages, azure and gcs remain untested for now

[AdamGS]

Hi @m7kss1 thanks for your PR! I'll review it next week.

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

⚡ 4 improved benchmarks
❌ 4 regressed benchmarks
✅ 1505 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	baseline_eq[4, 65536]	186.5 µs	239.2 µs	-22.02%
❌	Simulation	baseline_lt[16, 65536]	219 µs	276.8 µs	-20.87%
❌	Simulation	baseline_lt[4, 65536]	202.3 µs	254.4 µs	-20.47%
❌	Simulation	baseline_eq[16, 65536]	231.4 µs	261.7 µs	-11.57%
⚡	Simulation	bitwise_not_vortex_buffer_mut[128]	275.3 ns	216.9 ns	+26.89%
⚡	Simulation	bitwise_not_vortex_buffer_mut[1024]	336.9 ns	278.6 ns	+20.94%
⚡	Simulation	bitwise_not_vortex_buffer_mut[2048]	400.6 ns	342.2 ns	+17.05%
⚡	Simulation	encode_varbin[(1000, 2)]	164.1 µs	143.1 µs	+14.65%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing m7kss1:feat-cloud-object-store (c952c6d) with develop (e06d80b)}

[robert3005]

You have one failing test case on windows object_store::cloud::tests::test_resolve. Otherwise I think this looks good.

[AdamGS]

This should be configurable

[m7kss1]

@AdamGS indeed, but if we make them configurable, should we keep the current ones as defaults + change api to allow use custom properties? in trunk, these settings are hard-coded, so this should be handled extra carefully (ref: https://github.com/vortex-data/vortex/blob/develop/vortex-jni/src/object_store.rs#L71-L78)

[AdamGS]

I've added a few more focused comments, but I think there are two bigger issues here:

1. I don't think this quite solves the issue you describe in the PR.
   While it does centralize the implementations (which I agree is desirable), it keeps some of inconsistencies between them. The registry is a lot more configurable than make_object_store, which hard-codes a few assumptions.
2. It introduces a bunch of new public APIs like the Registry but more importantly ObjectStore, which is currently a crate we use in non-rust integrations and CAN work with for rust codebases when it makes sense for the user. I think our current IO traits will likely change, but still we should probably use them externally.

[m7kss1]

@AdamGS thanks, that's a good point. the idea behind this approach was to avoid making any major changes to the current workflow and reuse as much as possible from the original implementation, to unlock the possibility for future refactoring in other crates. though, i think we can make them directly inside this MR, so I've temporarily marked MR as a draft and will ping you once i've finished the changes