[libraries/pod]: add PodOption type

[febo]

Problem

Optional values usually require an extra byte to indicate whether the value is present or not. This can affect the alignment of a type, which is not ideal.

Solution

This PR adds a PodOption, which is a generic type that can be used as a Pod to wrap a type as a Option. It works over types that implement a Nullable trait in order to indicate whether its value represent a None or not.

For example, a PodOption<u8> assumes the a 0 value is a None and any value different than 0 is Some.

/// Trait for types that can be `None`.
///
/// This trait is used to indicate that a type can be `None` according to a
/// specific value.
pub trait Nullable: Pod {
    /// Indicates whether the value is `None` or not.
    fn is_none(&self) -> bool;
}

impl Nullable for u8 {
    fn is_none(&self) -> bool {
        *self == 0
    }
}

The PR includes implementation for all integer types and Pubkey.

[joncinque]

Looks really good! Just a few small things on my side

[buffalojoec]

The API itself is clean, but I'm generally concerned with defaulting to zero values as None for integers.

I wonder if instead we should architect this type around "nonzero" integers, so the distinction is clear?

https://docs.rs/bytemuck/latest/bytemuck/trait.ZeroableInOption.html

[buffalojoec]

This is on the right track, @febo! I've just added some suggestions on the trait implementations.

I still think you can add to this type's API to make its use a little bit more ergonomic. I still believe it should at least offer is_some() and is_none() directly on the type.

Up to you, but I think COption does a great job of providing an API similar to Rust's Option, which makes it feel more comfortable to use.

https://github.com/anza-xyz/agave/blob/master/sdk/program/src/program_option.rs

[febo]

This is on the right track, @febo! I've just added some suggestions on the trait implementations.

I still think you can add to this type's API to make its use a little bit more ergonomic. I still believe it should at least offer is_some() and is_none() directly on the type.

Up to you, but I think COption does a great job of providing an API similar to Rust's Option, which makes it feel more comfortable to use.

https://github.com/anza-xyz/agave/blob/master/sdk/program/src/program_option.rs

@buffalojoec I cleaned up the API based on your review, let me know what you think.

[buffalojoec]

Looks great! Ship it!

[joncinque]

Just a few flyby comments that I hope will remove some footguns

[joncinque]

This assumes that T::default() is the None value, which is not guaranteed by the trait. I understand the desire to make the value flexible, so to make that behavior less error-prone, how about changing the trait to something like:

pub trait Nullable: Pod + PartialEq + Sized {
    /// Value indicating the `None` to check against
    const NONE: Self; 
    /// Indicates whether the value is `None` or not.
    fn is_none(&self) -> bool {
        self == &Self::NONE
    }

[febo]

The only caveat is that in this case NONE value has to be a const. I don't think is a big deal, but perhaps we can consider adding a method to the trait to specify the NONE value.

• Using const NONE:

  impl Nullable for Pubkey {
      const NONE: Self = Pubkey::new_from_array([0u8; PUBKEY_BYTES]);
  }

• Using none() method:

  impl Nullable for Pubkey {
      fn none() -> Self {
          Pubkey::default()
      }
  }