fix(services/fs): make content-length mandatory in list() responses

[PiyushXCoder]

Which issue does this PR close?

Partially addresses #7062

Rationale for this change

Issue #7062 proposes making content-length a mandatory return value in list operations across all OpenDAL services. Previously, content-length was handled on a best-effort basis, requiring users to call stat separately when they needed this information. This placed unnecessary burden on users and caused confusion.

This PR starts addressing this issue by implementing mandatory content-length returns in the filesystem service's list operation.

What changes are included in this PR?

• Modified FsLister implementation to always include content-length in list responses
• Added metadata() calls to retrieve file/directory size information during listing
• Updated entry creation for all entry types (DIR, FILE, Unknown) to include content length
• Ensures consistent metadata retrieval for both the current path and directory entries

Key changes in core/services/fs/src/lister.rs:

• Retrieves metadata using tokio::fs::metadata() for the current directory path
• Calls de.metadata() for each directory entry during iteration
• Applies with_content_length() to all Metadata objects before creating entries

Are there any user-facing changes?

Yes - Users of the filesystem service will now always receive content-length information in list responses without needing to make additional stat calls. This improves the API ergonomics and reduces the number of system calls needed to gather complete file information.

This is a non-breaking enhancement - existing code will continue to work, but users can now rely on content-length always being present for filesystem list operations.

AI Usage Statement

No AI has been used

[PiyushXCoder]

With changes