build: remove unnecessary allocator-api2 dep.

[ErichDonGubler]

Hey there @kyren! 👋🏻 Positive heckler at 0:29 of your RustConf 2018 talk here. 🙂 We (sorta) meet again!

This time, I come representing some dependency management effort at Mozilla, where I've been auditing dependencies of crates like libsqlite 0.31, which includes hashlink 0.9.0. We've used previous versions of hashlink via this transitive dependency, but hashlink's update to hashbrown 0.14 has an interesting wrinkle in it: it includes the allocator-api2 feature/dependency combo by default. But…it doesn't seem like it's being meaningfully consumed by most crates using hashbrown, including hashlink's case. 😖

Turns out, this feature probably doesn't make sense unless a consumer-of-a-consumer crate (i.e., something using hashlink) uses allocator-api2 directly and has access to the allocators that hashlink's underlying hashbrown collections use (which isn't currently exposed). So, I disable this feature with this PR for Mozilla's sake. End-user applications can still re-enable this with a direct dependency on hashbrown, with which they can request the hashbrown/allocator-api2 themselves.

I don't know why hashbrown made this a default feature, TBH. 🫤 It's been annoying (but doable) to combat this unnecessary dependency in other crates like gpu-descriptor (see zakarumych/gpu-descriptor#40).

[kyren]

Hey there @kyren! 👋🏻 Positive heckler at 0:29 of your RustConf 2018 talk here. 🙂 We (sorta) meet again!

That's probably the friendliest introduction to a PR I've ever gotten haha. Nice to see you again! 👋

Yeah, this makes complete sense and I'm gonna merge it. Do you need me to do another hashlink release to get everyone lined up?

Just let me know!

[ErichDonGubler]

@kyren: Yes please! A release would definitely facilitate, but is not hard-blocking for us. Thank you so much! 😊

[kyren]

Okay, release is done!