Remove blocking API entirely from raw::Access

[Xuanwo]

OpenDAL supports both blocking and asynchronous APIs. However, over time, this design has created a significant maintenance burden. Few services truly have blocking API support, yet we all have to invest considerable effort in duplicating code throughout the project.

Maybe it's time for us to remove blocking API entirely from raw::Access. And only keep BlockingOperator as a wrapper of Operator.

After this change:

• raw::Access will only have async API which can reduce a lot of duplicated code, especially in layers.
• Existing API on BlockingOperator won't be affected.
• BlockingLayer could be removed and related APIs been moved to BlockingOperator instead.

Benefits:

• OpenDAL's codebase can be reduced a lot, as all services and layers could cut the number of generated functions by half.
• OpenDAL can accelerate development by eliminating the need to implement the save feature separately for both async and blocking modes.
• OpenDAL can now provide tokio/monoiofs/compfs as alternative.

[Xuanwo]

I'm talking to some known opendal::BlockingOperator users about this change:

• Question: What will happen if OpenDAL changes its BlockingOperator implementation? zarrs/zarrs#190
  • response: "That is not a problem at all"
• Question: What will happen if OpenDAL changes its BlockingOperator implementation? ixlab/vidformer#23
  • response: "That would have minimal impact on me." and "If it makes your life easier, by all means rip it out."
• Question: What will happen if OpenDAL changes its BlockingOperator implementation? bmrlab/gendam#113
  • response: "no worries, this change won't affect us."
• Question: What will happen if OpenDAL changes its BlockingOperator implementation? Mivik/bijou#3
  • response: "It would break the code but wouldn't be a lot, as wrapping an executor runtime could make stop the async from propagating further."

[sundy-li]

I agree that if the async IO could work better than blocking the IO.

[jorgehermo9]

+1, very good idea.

[Xuanwo]

Thank you all for the discusson, I have start an RFC for this change. Welcome to review it!

#6189