Implement `slice(&self, range: impl RangeBounds<usize>)` for `HeaderValue`

Inizia esaminando le API esistenti di HeaderValue per lo storage condiviso, quindi ispeziona Bytes::slice e l’alternativa discussa in issue #459. Determina quale interfaccia vogliono i maintainer e considera il comportamento degli intervalli e le implicazioni dell’ownership; il lavoro è completato quando l’API scelta è implementata con una copertura e una documentazione adeguate.

_{NB. I initially opened this issue suggesting implementing std::ops::Index instead of a slice method. That original proposal wouldn't work because the trait would always returns a &HeaderValue (a &<Self as Index>::Output) and I'm proposing a method that returns an owned HeaderValue.}

My motivation for this is to simplify handling list-based header values in a way that avoids copying the HeaderValue's data. Consider If-None-Match, which may contain multiple comma-separated entity-tags, or Cookies which may contain multiple semicolon-separated cookie-pairs. In both cases, it's necessary to operate on individual values within the list, and sub-slicing is a natural choice;

let inm = HeaderValue::from_static(
    r#"If-None-Match: W/"67ab43", "54ed21", "7892dd""#,
);
assert_eq!(&inm.as_bytes()[15 .. 25], br#"W/"67ab43""#);
assert_eq!(&inm.as_bytes()[27 .. 35], br#""54ed21""#);
assert_eq!(&inm.as_bytes()[37 .. 45], br#""7892dd""#);

The above works well if 1. you can limit operations to &[u8]s and 2. you can manage the lifetime of the borrowed-from HeaderValue. Both of those limitations seem unnecessary given HeaderValue's Arc-like memory characteristic, so it's more natural to my mind to allow something like the below,

let inm = HeaderValue::from_static(
    r#"If-None-Match: W/"67ab43", "54ed21", "7892dd""#,
);
assert_eq!(inm.slice(15 .. 25), HeaderValue::from_static(r#"W/"67ab43""#));
assert_eq!(inm.slice(27 .. 35), HeaderValue::from_static(r#""54ed21""#));
assert_eq!(inm.slice(37 .. 45), HeaderValue::from_static(r#""7892dd""#));

This would be a relatively simple change to make using Bytes::slice to do the heavy lifting.

I haven't put together a PR for the above yet because I see two open questions that I feel a maintainer may want to weigh in on.

First is whether or not this should be done at all. Returning a HeaderValue from a method named slice (rather than a &HeaderValue) may be surprising in the broader context. It would also implicitly codify the use of Bytes — or some other Arc-like memory management system — in the type's interface. I don't see either of these as blockers, given from_maybe_shared is precedent for both, and HeaderValue has been backed by Bytes for years now.

Second, and maybe more interesting, is whether this kind of interface would be better or worse than directly exposing the underlying Bytes object as per #459. Rather than offering a HeaderValue::slice method, consumers could directly call Bytes::slice, e.g.

let inm = HeaderValue::from_static(
    r#"If-None-Match: W/"67ab43", "54ed21", "7892dd""#,
);
let b_inm: Bytes = inm.as_shared();
assert_eq!(b_inm.slice(15 .. 25), Bytes::from_static(r#"W/"67ab43""#));
assert_eq!(b_inm.slice(27 .. 35), Bytes::from_static(r#""54ed21""#));
assert_eq!(b_inm.slice(37 .. 45), Bytes::from_static(r#""7892dd""#));

I'd be happy to put up a PR for either change.