DISCUSS: Should we integrate Apache OpenDAL support in Parquet?

Hello community,

I'm interested in integrating [Apache OpenDAL](https://github.com/apache/opendal) support into `parquet` (and potentially other crates) to enable more users to benefit from this first-class support. This integration allows users of both `parquet` and `opendal` to enjoy a better experience.

Do you think it would be a valuable addition?

## Backgroud

[OpenDAL](https://github.com/apache/opendal) is a unified data access layer designed to simplify interactions with various storage backends, ranging from AWS S3 to Google Drive and more. Its integration into parquet could allow opendal users to use parquet more easily and allowing parquet users to visit more storage backends.

Although it's possible to use `opendal::Reader` as `AsyncRead + AsyncSeek` in the parquet `ParquetRecordBatchStream`, its performance isn't optimal compared to `ParquetObjectReader`, which directly utilizes the `object_store` API.

## Benefits

OpenDAL, a graduated Apache project with robust community support, boasts 22 committers and 182 contributors. This integration could potentially bring additional committers to the Arrow community.

This integration enhances the user experience for both `parquet` and `opendal`. Users of `parquet` gain easy access to additional storage services, while `opendal` users can seamlessly integrate with `parquet`.

## Plan

### For implementation

Thanks to parquet & object_store perfect design, we can:

- Introduce a new feature named `opendal`, similar to how we handle `object_store`.
- Implement `ParquetOpendalReader` analogous to `ParquetObjectReader`. Other structures could adopt the same design pattern.
- Since we only require opendal's public API, we can disable all service features to minimize the dependency tree.

### For maintenance

Many opendal committers heavily utilize parquet. If this proposal is accepted, the opendal community (like me) will actively maintain the OpenDAL component, including its API, documentation, tests, and CI. Additionally, the opendal community will be responsible for managing bug reports and feature requests related to OpenDAL.

## Alternatives

### Why not through `object_store_opendal`?

While it's feasible for `opendal` to function as an `object_store::Store` via `object_store_opendal`, this approach requires extra effort from the user and limits optimization opportunities for OpenDAL, such as selecting read methods based on if service has native seek support.

### Why not implement externally?

Although implementing this feature externally is possible, providing native support simplifies discovery and adoption for users.

For examples, some users have to implement their own parquet reading logic:

- [greptimedb](https://github.com/GreptimeTeam/greptimedb/blob/bf5e1905cd7f4987a504d650a00ca6501cd5203c/src/mito2/src/sst/parquet/helper.rs)
- [databend](https://github.com/datafuselabs/databend/blob/3340c38f77b7643a509df5bcaacb2d5ced516b5f/src/common/storage/src/parquet2.rs)

By contributing `ParquetOpendalReader` upstream, we can unite community efforts.

Start by reviewing the existing `ParquetObjectReader`, `ParquetRecordBatchStream`, and the `object_store` feature to understand the proposed integration points. Before implementation, resolve whether native OpenDAL support is accepted and agree on the feature, reader API, dependency configuration, documentation, tests, and CI scope; done means those decisions are settled and the resulting support is covered accordingly.

Written by the indexing model from the issue text.