RHashMap::raw_entry[_mut] support

[marioortizmanero]

This PR adds support for the upcoming raw_entry API. This is possible by switching to hashbrown instead of std. Furthermore, this PR enables support for halfbrown, an empirically more performant implementation of hashbrown, with support for raw_entry, too:

Hashmap implementation that dynamically switches from a vector based backend to a hashbrown based backend as the number of keys grows

The halfbrown part works by switching the underlying struct for RHashMap to a halfmap::HashMap when activated. Its interface is meant to be the same as hashbrown's.

The only error I haven't been able to fix is the following, any help?

error[E0271]: type mismatch resolving `<iterator_stuff::RefIterInterface<K, V> as erased_types::traits::InterfaceType>::Clone == impl_enum::Unimplemented<type_leve
l::trait_marker::Clone>`
   --> abi_stable/src/std_types/map/extern_fns.rs:123:13
    |
123 |             DynTrait::from_borrowing_value(iter, RefIterInterface::NEW)
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `impl_enum::Unimplemented`, found struct `impl_enum::Implemented`
    |
    = note: expected struct `impl_enum::Unimplemented<type_level::trait_marker::Clone>`
               found struct `impl_enum::Implemented<type_level::trait_marker::Clone>`
note: required because of the requirements on the impl of `erased_types::vtable::GetVtable<'_, std::iter::Map<halfbrown::Iter<'_, map_key::MapKey<K>, V>, fn((&map_
key::MapKey<K>, &V)) -> tuple::Tuple2<&K, &V> {map_iter_ref::<'_, K, &V>}>, std_types::boxed::private::RBox<()>, std_types::boxed::private::RBox<std::iter::Map<hal
fbrown::Iter<'_, map_key::MapKey<K>, V>, fn((&map_key::MapKey<K>, &V)) -> tuple::Tuple2<&K, &V> {map_iter_ref::<'_, K, &V>}>>, iterator_stuff::RefIterInterface<K,
V>>` for `interface_for::InterfaceFor<std::iter::Map<halfbrown::Iter<'_, map_key::MapKey<K>, V>, fn((&map_key::MapKey<K>, &V)) -> tuple::Tuple2<&K, &V> {map_iter_r
ef::<'_, K, &V>}>, iterator_stuff::RefIterInterface<K, V>, downcasting::TD_Opaque>`
   --> abi_stable/src/erased_types/vtable.rs:333:13
    |
333 |               GetVtable<'borr,$value,$erased_ptr,$orig_ptr,$interf>
    |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
334 |           for This
    |               ^^^^
...
495 |   declare_meta_vtable! {
    |  _-
    | |_|
    | |
496 | |     interface=I;
497 | |     value  =T;
498 | |     erased_pointer=ErasedPtr;
...   |
757 | |     ]
758 | | }
    | | -
    | |_|
    | |_in this macro invocation
    |   in this macro invocation
note: required by a bound in `priv_::DynTrait::<'static, rref::RRef<'static, ()>, ()>::from_borrowing_value`
   --> abi_stable/src/erased_types/dyn_trait.rs:877:44
    |
870 |         pub fn from_borrowing_value<'borr, T, I>(
    |                -------------------- required by a bound in this
...
877 |             InterfaceFor<T, I, TD_Opaque>: GetVtable<'borr, T, RBox<()>, RBox<T>, I>,
    |                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `priv_::DynTrait::<'static, rref::RRef<'static
, ()>, ()>::from_borrowing_value`
    = note: this error originates in the macro `declare_meta_vtable` (in Nightly builds, run with -Z macro-backtrace for more info)

I understand that the way to fix it would be to remove Clone from here:

declare_iter_interface! {
    K => V;
    /// The `InterfaceType` of the `Iter` iterator for `RHashMap`.
    #[sabi(impl_InterfaceType(Iterator, Clone))]
    interface = RefIterInterface;
    type Item = Tuple2<&'a K, &'a V>;
}

But then I get errors, because .clone() is actually used a few times.

TODO:

• Fix error above
• Disable hashbrown when halfbrown is being used? That would mean hashbrown would also be a (default) feature. But if someone uses --no-default-features it would fail without also adding hashbrown back.
• Update the tests and the docs
• Implement "nightly" features for halfbrown/hashbrown:
  • insert_nocheck
  • raw_entry
• Wait for Fix hasher #85 and rebase (this branch points to it right now, so the diff is a bit messed up)

[marioortizmanero]

Here's an update about the status of this PR.

I have concluded my work with Tremor, so I won't be able to continue working on it. For now, the PR is just part of research in trying to optimize Tremor's plugin system. It analyzes halfbrown vs hashbrown, and memoizing JSON hashes (see https://nullderef.com/blog/plugin-end/#_hash_table_optimization). If the rest of the Tremor team end up considering this worth implementing, then some more polishing is still required. The wrapped API is incomplete, and doesn't include the builder pattern for simplicity.

Even if the change ends up being worth it, I'm not fully sold on merging it into the main branch. raw_entry isn’t going to make it to a stable release, and the Rust team is working on a different interface. It will probably be similar enough that updating our raw_entry usage won’t be too much work, but we should make sure first to minimize the breaking changes.

Any more doubts please let me know!