Prefer slice argument when passing in content key

[carver]

This change probably looks a little surprising in isolation. Right now it causes an extra clone (because we were previously able to move in a vector that now has to be cloned inside the method).

Here is a super draft-y PR to help show the context of where I think it makes more sense:
https://github.com/ethereum/trin/pull/166/files#diff-fd7cee899607b5a0b4e30853e7bb9f8a191ed26926c7724f6b66d3070f62cf56R67-R72

Also, at some point, it should be possible to build the request from a slice without copying it first. It just doesn't seem like a priority now. But we might as well prepare the API to head that direction IMO. As always, open to discussion.

[lithp]

Definitely a bit surprising but looks good to me!

A pattern I've seen is to accept a generic Into<Vec<u8>> type, then call .into() on the passed argument. example.

This should work here because Vec<T> implements From<&'_ [T]>, and it gives callers the freedom to pass in whatever is most convenient for them without needing to do any manual conversions.

And since the specialization happens at compile time there's a good chance that the code only ends up doing as many copies as are necessary. (If a Vec is passed in then it's simply moved into the correct position in the new struct)

[carver]

Beautiful, yes, this looks like the best convention I've seen so far. I'll update to this before merging.

A pattern I've seen is to accept a generic Into<Vec<u8>> type, then call .into() on the passed argument. example.

@njgheorghita check out the example link above, it's a great way to minimize cloning and make it easier for the caller to use whichever type is more convenient.