Fix sometimes-unused dependencies

[jplatte]

Analysis done with cargo-udeps.

[jplatte]

Rebased. Ping @davidpdrsn can you review this?

[davidpdrsn]

I think this looks good but would like someone else to +1 as well. cc @hawkw @olix0r

[olix0r]

CI fails because this change introduces unsafe code into a module that uses forbid(unsafe). I'd prefer to revert that part of the change (i.e. continue using pin-project-lite) so that we can avoid unsafe code in this crate.

pin-project-lite is almost definitely going to be in your dependency tree if you're using tokio.

[davidpdrsn]

I believe the issue is that moving Either to pin-project-lite is a breaking change.

[olix0r]

I believe the issue is that moving Either to pin-project-lite is a breaking change.

That's a little surprising to me. Does pin-project-lite change the API surface when compared to pin-project? Howso?

If we can't use lite, I'd still prefer continuing use of pin-project if the alternative is adding unsafe code to tower -- it just expands the audit surface area. We're due for a breaking change sometime soon, I think, anyway. So we should get an issue to switch to use lite then if we really can't change now.

[jplatte]

The issue with using pin-project-lite for Either is that it doesn't support tuple structs or tuple variants in enums. I don't think you would want to change ``Either::A(A)toEither::A { inner: A }`, right? In that case, the only options are to keep the `pin-project` dependency or accept the tiny bit of unsafe code. IMHO, the latter is better.

I'll separate that change from this PR though given that the other changes seem less controversial.

[olix0r]

@jplatte That makes sense. Thanks for splitting out the change. We'll continue the conversation in #629