This patch contains a special hack that circumvents the current tokio
seek problem.
tokio `seek` is implemented to take ownership of the original File and
emit a new one in its future, which conflicts with the design of
ResourceTable.
To avoid the problem, the current hack makes the FsFile resource
an Option which we could `take` the value ownership out of it. We then
convert the tokio File into a Rust std File, perform the seek, and then
put it back into the resource.
This might be able to drop this hack after
https://github.com/tokio-rs/tokio/pull/785 lands.
Because many Reader/Writer implementations (e.g. bufio) assume their
able to use subarray() with byte indexes and often ask for byte values,
it makes sense to simply restrict all implementations to Uint8Array.
This will improve the threshold benchmark. Using 32k because that's what
Go uses, but we should explore the value in the future.
a0d6420d8b/src/io/io.go (L391)
