feat(bindings/nodejs): Add ReadOptions and ReaderOptions support for new options API

[kingsword09]

Which issue does this PR close?

Related to #6281.

Rationale for this change

This PR adds support for opendal::options::ReadOptions and opendal::options::ReaderOptions conversion in the nodejs bindings. This is part of the migration to the new options API outlined in RFC-6213 (#6213).

What changes are included in this PR?

• Added a complete mapping and conversion of opendal::options::ReadOptions and opendal::options::ReaderOptions
• behavior tests mirroring Rust's async_read.rs test suite
• Added the capabilities to support the options

Are there any user-facing changes?

Yes, users can now add options to their read and reader requests

[kingsword09]

Limit range request to 3MB because the etcd service enforces a 4MB gRPC message size limit, and larger requests will fail.

https://github.com/apache/opendal/actions/runs/15731991430/job/44335059868?pr=6312#step:9:493

[kingsword09]

@Xuanwo @suyanhanx We need to clarify whether the “size” parameter should represent the number of bytes to read after the offset (length-based), or if it should specify the absolute end bound (end-based) for the read operation.

I noticed that in the Python binding, “size” is actually used as the end bound, but the name “size” doesn’t seem to accurately reflect this usage.

opendal/bindings/python/tests/test_read.py

Line 80 in 06370cc

with operator.open(filename, "rb", offset=range_start, size=range_end) as reader:

Currently, I am using “size” to indicate the number of bytes to read after the offset. Should I align this behavior with the Python binding, where “size” is used as the end bound?

[Xuanwo]

I noticed that in the Python binding, “size” is actually used as the end bound, but the name “size” doesn’t seem to accurately reflect this usage.

Hi, I believe your understanding is correct. The size refers to this reading's size, and our actual read range should be offset..offset+size.

[Xuanwo]

Hi, @kingsword09, is this PR ready to go?

[kingsword09]

Hi, @kingsword09, is this PR ready to go?

Yes

[Xuanwo]

Nice work, let's go!