Consider Using ZeroTrie, Option Types in Units Conversion Provider and removing dimensions

[younies]

In the experimental/unitsconversion/src/provider.rs file, there are a couple of potential improvements that could be made to enhance the code quality and maintainability.

1. Consider using ZeroTrie: Currently, we are using ZeroMap to map from unit name to indices.

/// Maps from unit name (e.g. foot) to the index of the unit in the `unit_quantity` vector.
#[cfg_attr(feature = "serde", serde(borrow))]
pub units_info: ZeroMap<'data, str, UnitsInfoIndex>;

2. Consider using Option<Dimension> and Option<ConversionInfo>: Currently, we are using indices to reference the Dimension and ConversionInfo in their respective vectors.
3. Consider removing the dimension from the units conversion data. During the units conversion, not all the users wants to know the dimension. For example: acre's dimension is area

[robertbastian]

pub struct UnitsInfoV1<'data> {
    pub units: ZeroMap<'data, str, UnitULE>,
    pub dimensions: VarZeroVec<'data, DimensionULE>,
}

pub struct Unit<'data> {
    // u16 is cheaper than Option<u16>, and it lets us skip searching for the base unit's dimension
    pub dimension: u16,
    pub conversion: Option<Conversion<'data>>,
}

pub struct Dimension<'data> {
    pub quantity: Cow<'data, str>,
    pub specifier: DerivationSpecifier,
}

pub struct Conversion<'data> {
    pub base_unit: u16, // this is an index into `units`'s keys (which therefore cannot be ZeroTrie)
    pub exactness: Exactness,
    pub term: Term<'data>
}

// Use a custom encoding:
// [sign, 0nnnnnnn, 0nnnnnnn, 1nnnnnnn, 0ddddddd, 1ddddddd, sign, 1nnnnnnn, 1ddddddd]
// Compared with ZeroVecs:
// + don't need MultiFieldVarULE.
// + varint encoding is cheaper for the common case of short numbers.
// - varint encoding is more expensive for long numbers (I don't think we'll actually hit this)
// = both options have to allocate to create a BigUint
pub struct Term<'data>(Cow<'data, [u8]>);

impl Term<'data> {
    pub fn apply(&self, x: ?) -> ? {
        // We might not actually want to use BigUint, as it allocates a lot.
    }
}

impl Serialize for Term {
     // something nice for JSON, like "* 8349 / 138934 + (9434 / 8394)"
}

[sffc]

I can export the varint functions from ZeroTrie if useful.

We can get rid of more bytes by stuffing the sign into the numerator.

[robertbastian]

I can export the varint functions from ZeroTrie if useful.

huh? where would that be used?

We can get rid of more bytes by stuffing the sign into the numerator.

Yes we can make the first byte a 6-bit varint

[sffc]

We already have varint code in the zerotrie crate that we could possibly leverage.