Expose OpenDAL service protocols through fsspec entry points

[PsiACE]

Follow-up to the entry-point discussion in #85.

Current behavior

fsspec discovers third-party filesystems from the fsspec.specs entry-point group. Each entry-point name is registered as an exact protocol and its filesystem class is imported lazily when the protocol is first used.

Because protocol lookup is exact, an opendal+<service> URL can only be used directly when that complete protocol has been registered. There is no opendal+* or prefix-based fallback.

opendalfs currently publishes entry points for three services:

• opendal+s3
• opendal+gcs
• opendal+azblob

Other OpenDAL services require an explicit call to register_opendal_service(). This creates and registers a service-specific filesystem class for the current Python process.

Tier 0 services

We should define an explicit set of Tier 0 services as the stable, installation-time protocol surface of opendalfs.

For every Tier 0 service, opendalfs should:

• publish an exact opendal+<service> entry point;
• provide stable URL and path semantics;
• support discovery without importing opendalfs or calling a registration function first;
• maintain the corresponding adapter, tests, and documentation.

The Tier 0 service set should be the single source of truth for the built-in service adapters, packaged entry points, and default protocol registration.

Services outside Tier 0 can continue to use register_opendal_service(). This keeps additional OpenDAL services available without including every service in the default compatibility guarantee.

[Xuanwo]

Maybe we should also provide an API to allow override? Like use s3://bucket directly.

[Xuanwo]

Also asking for @martindurant's idea. What do you think? How to handle a fs that can serve different backends?

[martindurant]

I think the only other FS that accepts different protocols for different backends is arrow, and that is only realistically used with HDFS (because s3, etc are not any better). Other FS classes support different backends in the sense of compression engines (by keyword) or chained.

In your case, I think it is fine to populate the opendal+* protocols in known-implementations as you feel is correct. Also, providing the call which adds less prominent ones or overrides existing ones (like "s3") is also fine, if accurately documented. After all, these will not affect anyone that doesn't explicitly choose to call them.