uint: optimize FromStr, make it no_std-compatible

[vorot93]

Removes a Vec allocation, and a String creation in odd length path.

As I had to change underlying hex impl from rustc-hex to hex, the resulting error type changed as well. This is a breaking change.

[dvdplm]

I like the change from rustc-hex to hex and I think it's the right path. I agree with @ordian that it'd be good to avoid repeating the same mistake again and leak error types; an opaque Error type seems good here.

I'm less convinced by the buffer-length gymnastics; unless there's a compelling performance win I think I prefer the readability of the previous code over what is here. Can you provide a benchmark that proves a substantial speedup of the code?

[vorot93]

@dvdplm Added bench:

Before PR:
from_str time: [2.4288 us 2.4715 us 2.5148 us]

With PR changes:
from_str time: [752.62 ns 756.82 ns 761.81 ns]

But even more importantly, by avoiding Vec and String, we can enable FromStr implementation for no_std targets without alloc.

[ordian]

Looks fine. I guess we're trading readability here for perf and no_std support.
Would be nice to add more test case of length 0, 1, 3 and bring back the previous test case.

[dvdplm]

I can confirm the perf improvement, 2 - 2.5x.

[niklasad1]

I find this code hard to read, it could maybe be possible to refactor to avoid repeating let out = &mut bytes[BYTES_LEN - encoded.len() / 2..]; and $crate::hex::decode_to_slice(encoded, out).map_err(Self::Err::from)?; twice.

[vorot93]

I'm not sure it's possible because owning buffers are of different types (value: &str vs s: [u8; MAX_ENCODED_LEN]), different lengths and borrowing is involved here.

[niklasad1]

As Andronik said, would be good with a couple of tests with odd lengths of the hex str

[ordian]

Thanks!