no_std support

[olanod]

This PR turns the crate into no_std compatible replacing std references with core + alloc and adding the std feature where needed(std::error::Error support).
Also tried to make the dependency on HashMap optional making extensions an optional feature, the ahash dependency shouldn't be an issue since it's already a dependency of hashbrown which is the the std HashMap implementation.

[jplatte]

TypeId implements Ord, so how about using BTreeMap for extensions if there is no std, rather than not having it?

[algesten]

This looks really good. Wonder if the crate authors will get time to consider it?

[algesten]

Hm. I guess it doesn't get rid of allocations cause it relies on the extern crate alloc

[seanmonstar]

I'm not sure about getting this into 1.0, but I do want to allow for it. I think the only breaking change would be to add a std feature that is default-on, yea? Then we could eventually fix up support with it off.

[algesten]

Yes. I got a feeling i've seen more std feature flags than the opposite no_std. Either way works though.

[seanmonstar]

I created #637 which does that, allowing us to eventually add support later.

[olanod]

What's the current feeling about this feature, any must haves besides the basic support I initially added?

[bstrie]

What's the current feeling about this feature, any must haves besides the basic support I initially added?

@olanod I see that this PR takes into account that error::Error is only in std, not in core. However, core::error::Error will be stable in Rust 1.81 (releasing September 5), so that might make this easier to land... although then we have to consider bumping the MSRV, and this crate's MSRV is currently an extremely conservative 1.49 (based on a former MSRV of Tokio).

So it may be worth asking @seanmonstar what he thinks about either 1) accepting this as-is with Error-in-std-but-not-in-core, or 2) thinking about waiting until Tokio bumps their MSRV to at least 1.81 (which will take at least 6 months). In the event of the latter, maybe we could get no_std support merged on a beta release branch of the HTTP crate? no_std users presumably don't care about the entire Hyper/Tokio ecosystem, so it would be useful to them to have this crate available on no_std even if it's a parallel release branch from that being used by Hyper/Tokio.

[seanmonstar]

If I remember correctly, we made it so currently with feature disabled nothing compiles. So if we make it so some of it compiles without the feature, that's still just an addition. And adding the error impls back eventually would still be just an addition. Right?

[bstrie]

So if we make it so some of it compiles without the feature, that's still just an addition. And adding the error impls back eventually would still be just an addition. Right?

@seanmonstar That seems reasonable, yes. Although, if you're willing to allow the crate's MSRV to vary based upon whether or not the std feature is enabled, then another option would be to allow this feature to land while just conditionally importing either core::error::Error or std::error::Error, which seems reasonable at first blush.