feat(puffin): Add PuffinReader

[fqaiser94]

Part of #744

Summary

• Add PuffinReader

Context

• This is the fourth of a number of PRs to add support for Iceberg Puffin file format.
• It might be helpful to refer to the overarching PR from which these changes were split to understand better how these changes will fit in to the larger picture.
• It may also be helpful to refer to the Java reference implementation for PuffinReader here.

[liurenjie1024]

Thanks @fqaiser94 for this great pr, generally LGTM! Just some minor suggestions.

[liurenjie1024]

Should we consider using a LazyLock to initalize it? This way it could be thread safe, and discard the &mut modifier.

[fqaiser94]

I would love to be able to get rid of the &mut here 👍
Struggling to get a LazyLock based implementation working though.
The main challenge is that FileMetadata::read is an async function :/
Open to suggestions

[liurenjie1024]

I think async_lazy crate is a good fit?

[fqaiser94]

PTAL, I implemented the lazy initialization using tokio::sync::OnceCell.

I couldn't get the async lazy crate approach to work because:

1. It doesn't expose any APIs for fallible operations.
2. My FileMetadata::read function needs a reference to the InputFile which doesn't work well with this approach:

let file_metadata: Lazy<Result<FileMetadata>> = Lazy::new(|| Box::pin(async { FileMetadata::read(&input_file).await }));

mismatched types
expected fn pointer `fn() -> Pin<Box<(dyn futures::Future<Output = std::result::Result<puffin::metadata::FileMetadata, error::Error>> + std::marker::Send + 'static)>>`
      found closure `{closure@crates/iceberg/src/puffin/reader.rs:36:67: 36:69}`rustc[Click for full compiler diagnostic](rust-analyzer-diagnostics-view:/diagnostic%20message%20[2]?2#file:///Users/fq/src/iceberg-rust/crates/iceberg/src/puffin/reader.rs)
reader.rs(36, 57): arguments to this function are incorrect
reader.rs(36, 107): closures can only be coerced to `fn` types if they do not capture any variables
lib.rs(73, 12): associated function defined here

[liurenjie1024]

Should we add comment to explain that this is always uncompressed data?

[waynexia]

Or can we include a CompressionCodec in the Blob to indicate the compress method? (we can do this in a follow-up PR)

[fqaiser94]

Should we add comment to explain that this is always uncompressed data?

Done.

Or can we include a CompressionCodec in the Blob to indicate the compress method? (we can do this in a follow-up PR)

I can see where you're coming from and while I'm not completely opposed to the idea, I think I prefer to return the uncompressed data at this point. I will also note that the Java PuffinReader API does the same i.e. always returns the data after decompression.