chore: bump opendal to 0.54.1

[dqhl76]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

This PR bump OpenDAL to 0.54.1.

OpenDAL v0.54 have implemented RFC-6189, which removes all native blocking I/O support.

In the new version, all blocking operations are handled by block_on, which is a wrapper around the asynchronous core. Consequently, there is no longer a performance benefit to be gained from services that support blocking I/O natively.

This PR removes the code branches that checked for operator.info().native_capability().blocking to select a blocking operation.

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (bump version):

---

This change is 

[github-actions]

Docker Image for PR

• tag: pr-18970-a7795c7-1763361766

note: this image tag is only available for internal use.

[github-actions]

ClickBench Report

• hits: https://benchmark.databend.com/clickbench/pr/18970/19419663413/hits.html
• internal: https://benchmark.databend.com/clickbench/pr/18970/19419663413/internal.html
• load: https://benchmark.databend.com/clickbench/pr/18970/19419663413/load.html
• tpch: https://benchmark.databend.com/clickbench/pr/18970/19419663413/tpch.html

[chatgpt-codex-connector]

💡 Codex Review

databend/src/common/storage/src/stage.rs

Lines 125 to 134 in f078d6d

	async fn list_files(
	&self,
	operator: &Operator,
	thread_num: usize,
	max_files: Option<usize>,
	mut files: &[String],
	) -> Result<Vec<StageFileInfo>> {
	if let Some(m) = max_files {
	files = &files[..m]
	}

Guard file list slicing by actual length

In StageFilesInfo::list_files the new async implementation blindly slices the provided file list with files = &files[..m] whenever the caller passes max_files (src/common/storage/src/stage.rs lines 125‑134). If max_files is larger than the number of explicitly enumerated files, this indexing panics with index out of bounds, aborting queries such as COPY INTO ... FILES=('a','b') MAX_FILES=10. The previous blocking implementation iterated and truncated the result without panicking, so this regression makes valid user input crash the server. Please clamp m to files.len() before slicing (e.g. files = &files[..m.min(files.len())]).

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[dqhl76]

the bug codex found can be reproduced by:

root@127.0.0.1:8000/default/default> copy into t from @s1 max_files = 10 files=('a.csv','b.csv') file_format = (type = CSV) force=true;
error: APIError: QueryFailed: [1104]range end index 10 out of range for slice of length 2

[dqhl76]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Chef's kiss.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".