update linkerd2-cache and linkerd2-lock to std::future

[hawkw]

This branch updates the linkerd2-cache crate (and linkerd2-lock,
which it relies on), to use std::future.

Unlike previous PRs, the linkerd2-lock update is a more substantial
rewrite, because upstream API changes made the previous implementation
no longer possible. In particular, tokio::sync::Mutex does not provide
a poll_acquire method the way that tokio_sync::Lock did in Tokio
0.1. The removal of poll_acquire is largely due to the rewrite of
Tokio's synchronization primitives to use an intrusive linked list-based
semaphore (tokio-rs/tokio#2325), which requires waiters to be pinned to
ensure safety of the intrusive list. Allowing permits to be acquired
only from a future ensures correct pinning of waiters.

Therefore, I've implemented a new Lock for Linkerd which uses a Tokio
Semaphore with 1 permit to ensure exclusive access. The Lock owns a
boxed instance of the future returned by Semaphore::acquire, and
drives it in poll_acquire. This allows adapting the poll-based Tower
interface with the futures-only, pinned interface.

[olix0r]

@hawkw looks like Cargo.lock is out of date?

[olix0r]

BTW, i published an updated version of our fork a while ago https://github.com/linkerd/webpki/tree/cert-dns-names-0.21

[olix0r]

@hawkw Would we still need the specialized Lock implementation if we altered the Cache implementation to avoid backpressure (i.e. by cloning the mutex into the response future)?

[olix0r]

I'm OK with this merging when it's green. I think, ideally, we ought to get rid of our lock implementation.... but that's not a blocker.

[hawkw]

@hawkw Would we still need the specialized Lock implementation if we altered the Cache implementation to avoid backpressure (i.e. by cloning the mutex into the response future)?

If we wanted to use Tokio's Mutex, it might also need to grow an owned-guard API like Semaphore has (which I can open a PR for). But, yeah, we could definitely do it that way (and it might be much nicer); I had kind of assumed that having Cache acquire the lock in poll_ready was a behavior we wanted to keep.

[olix0r]

@hawkw I'd have to check to confirm, but I believe we wrap all of these with oneshot, effectively

[kleimkuhler]

Looks like Cargo.lock still needs to be updated but changes look good!

[hawkw]

@hawkw Would we still need the specialized Lock implementation if we altered the Cache implementation to avoid backpressure (i.e. by cloning the mutex into the response future)?

If we wanted to use Tokio's Mutex, it might also need to grow an owned-guard API like Semaphore has (which I can open a PR for). But, yeah, we could definitely do it that way (and it might be much nicer); I had kind of assumed that having Cache acquire the lock in poll_ready was a behavior we wanted to keep.

tokio-rs/tokio#2455 merged upstream, so we could definitely do this. Also, we can now remove all the unsafe in this PR and use Tokio's mutex directly, even if we did decide to continue driving to readiness in poll_ready.

[olix0r]

lgtm, modulo the unrelated comment change