Note similarity between Rust references and reader-writer locks

* You could just use &Foo and &mut Foo (probably with lifetimes, at least if they're going into a struct). The main advantage is that these are the "lowest common denominator" - nearly everything else can be converted into one of these, except that pinning pointers cannot be converted into &mut. But none of the other generic options are compatible with Pin either (in this use case), so if you need to mutate through a Pin, you pretty much have to write it out separately (and hope the type supplies appropriate Pin<&mut Self> methods for actually doing the mutation). Unfortunately, the use of &Foo or &mut Foo means users will sometimes have to write &*foo or the like to convert some other type into a reference, which is not terrible but also not ideal.
* You could instead take Deref<Foo> and DerefMut<Foo>. This covers most reasonable smart pointers, in addition to &Foo and &mut Foo, which means the user can give us ownership (or shared ownership, a lock guard, etc.) if that is more convenient for them. Technically, there is nothing prohibiting a Deref implementation from doing something expensive like taking a lock, but the semantic meaning of Deref and DerefMut is "this conversion is so cheap and so obvious that it should happen implicitly," so taking a lock in Deref is evil (on top of that, the signature of Deref::deref() is not compatible with taking a lock unless you hold it for the entire lifespan of Self, so it makes more sense to implement Deref on the already-taken lock guard instead). For example, a Box<Foo> has all the methods of a &mut Foo, because even though it's technically not the same thing, we prefer to think of it as "a Foo that happens to live on the heap" rather than "a Box containing a Foo." Similarly, Vec<T> and [T; N] both deref coerce into &[T], because they're both conceptually "a contiguous sequence of T objects somewhere in memory," and so it would make no sense to require an explicit conversion to use slice methods on them. However, this can also be a problem, if you don't actually care about that property and just want "a thing that can cheaply and infallibly give me a &Foo, regardless of what it is conceptually supposed to be."
* Then there are AsRef<Foo> and AsMut<Foo>. These are the "cheap reference-to-reference conversion" traits. Just like Deref, they should not take locks or do other expensive operations (and just like Deref::deref(), their method signatures are not really compatible with locking anyway). Unlike Deref, they don't get invoked implicitly, which means that unlike Deref, you can implement them more than once on the same type, as well as on types that are conceptually distinct from one another. For example, the various string-like types can all be converted into &[u8] via AsRef, but they do not Deref as &[u8], because it would be very confusing if we mixed bytewise methods into the same namespace as Unicode-oriented methods. Unfortunately, &T does not blanket implement AsRef<T> due to a trait coherence constraint, which means these are not a good candidate for accepting arguments generically.
* There are also Borrow<Foo> and BorrowMut<Foo>. These are extremely similar to AsRef<Foo> and AsRefMut<Foo>, with two differences: Firstly, they semantically require that Self implements Eq, Ord, and Hash identically to the underlying (owned) type (i.e. if lhs == rhs, then lhs.borrow() == rhs.borrow()). This makes them suitable for use in hash tables, trees, heaps, etc. Secondly, there is a blanket implementation for &T, so they are more suitable for generic use than AsRef<T>. But you don't always need the Eq/Ord/Hash property, so this may be too restrictive in some use cases.
* In principle, there's also Into<&T>, but this doesn't exist in practice because the signature doesn't make sense (it consumes self and returns &T, but what is the lifetime of the &T it returns, given that self has been consumed and no longer exists?).

IMHO the least problematic option (at least in a case like this) is to take Deref<T> or DerefMut<T>, because:

* Conversion into &T or &mut T is rarely all that difficult (except for the Pin case noted above) and those always implement Deref/DerefMut.
* Most smart pointers are Deref<T>, so we still support the "pass an owning smart pointer or lock guard instead of a reference" use case. That's one less lifetime for the user to think about, but they don't have to do this if they don't want to (they can pass &T instead).
* If the end user wants to do some conversion that isn't "obvious" in the way that deref coercion is meant to be obvious, then probably they should do that explicitly at the callsite.

I'm actually not too upset about AsRef lacking that reflexive blanket implementation - if it had one, then it would be much easier to write generic code that does implicit conversions, and once that starts to become the standard way of writing generic code, everything starts feeling a little too much like C++ (before they invented the explicit keyword). In fact, part of me is tempted to say that they should not fix this, even if trait coherence gets more permissive in the future, because I'm not sure the resulting generality would be worth it. But OTOH that doesn't seem to have happened with From and Into, so maybe it's fine.