[Variant] Add primitive type timestamp_nanos(with&without timezone) and uuid

[klion26]

Which issue does this PR close?

• Closes [Variant] Add support the remaing primitive type(timestamp_nanos/timestampntz_nanos/uuid) for parquet variant #8126.

Rationale for this change

This PR adds remaining variant primitive types(timestamp_nanos/timestampntz_nanos/uuid)

What changes are included in this PR?

• Add primitive variant types for timestamp_nanos/timestampntz_nanos/uuid

Are these changes tested?

Added some tests and reusing existing tests

Are there any user-facing changes?

No

[klion26]

spec said that UUID is stored as big-endian
Tests failed because of UUID decoding/encoding, I need to verify it. Currently, use from_slice_le and to_bytes_le( from UUID crate, seems the result is different from the bytes generated from the iceberg code.

[klion26]

UUID is stored as big-endian

[klion26]

@alamb @superserious-dev Could you please help review this when you're free, thanks.

[alamb]

Thank you for this PR @klion26 🙏 ❤️

I left some comments -- the only one I think is important to change is the as_uuid_string --> as_uuid

Otherwise this is looking very nice

[alamb]

I double checked and this is correct compared to https://github.com/apache/parquet-format/blob/master/VariantEncoding.md#encoding-types

[alamb]

I don't understand this comment

[klion26]

Changed the implementation. When I implemented this, I did not notice that the DateTime::from_timestamp_nanos would never fail, added the comment to show why we use DateTime::from_timestamp instead of DateTime::from_timestamp_nanos

[alamb]

I think having this be as_uuid(&self) -> Option<Uuid> would be both more consistent with the other methods that access variant data, as well as being more performant -- the caller could decide if they wanted to pay the cost to convert to string as well

I think the example is great, and we could show it as a way to convert to strings

[klion26]

fixed

[klion26]

@alamb Thanks for your review, I've updated the pr, please take another look when you're free. thanks.

[klion26]

Changed the implementation. When I implemented this, I did not notice that the DateTime::from_timestamp_nanos would never fail, added the comment to show why we use DateTime::from_timestamp instead of DateTime::from_timestamp_nanos

[klion26]

fixed

[alamb]

Thank you @klion26 -- this looks good to me

[klion26]

@alamb thanks for the review. Updated the code to resolve the conflicts. The CI failed because of Error: Unable to locate package libpython3.11-dev, it seems it's irrelevant to the current pr

[alamb]

@alamb thanks for the review. Updated the code to resolve the conflicts. The CI failed because of Error: Unable to locate package libpython3.11-dev, it seems it's irrelevant to the current pr

Yes I think that is is also happening on main -- I filed a ticket to track

• The Rustdocs are clean CI job is failing #8175

[alamb]

Thank you @klion26

[klion26]

@alamb thank you for the review and merging!