Replace pin-project by pin-project-lite

[jplatte]

Motivation

pin-project-lite, in contrast to pin-project, does not depend on syn and quote and as such is much lighter on compile times. futures-rs switched recently, see that PR for compile time differences.

Solution

Replace pin-project by pin-project-lite.

Resolves #1178.

[jplatte]

CI failure seems unrelated.

[jplatte]

I've added a commit to appease clippy, let me know if you'd rather keep that out of this PR.

[jplatte]

Now there's a bunch more clippy warnings that I'm not as comfortable addressing.

[djc]

This looks good to me, would be nice to have.

[hawkw]

I'm a bit on the fence about whether or not to merge this in light of the discussion on #1185, e.g. #1178 (comment)

@taiki-e, as the maintainer of both pin-project and pin-project-lite, what would you recommend? I'll note that tracing already uses pin-project-lite rather than pin-project.

Another advantage of pin-project, IMO, that wasn't discussed in #1185, is that it has a 1.0 release, while pin-project-lite does not. If breaking changes of pin-project are much less likely than pin-project-lite, we won't have to release tracing-futures patches just to bump the pin-project dependency nearly as often — and it reduces the potential for multiple pin-project versions in users' dependency trees.

I could be convinced either way, though.

[taiki-e]

as the maintainer of both pin-project and pin-project-lite, what would you recommend? I'll note that tracing already uses pin-project-lite rather than pin-project.

If you are already using pin-project-lite in the same workspace, there is basically no reason to oppose this patch.
(However, note that a patch that recently tried to do the same with hyper caused a regression due to the pin-project-lite's limitation was missed. hyperium/hyper#2422)

Another advantage of pin-project, IMO, that wasn't discussed in #1185, is that it has a 1.0 release, while pin-project-lite does not. If breaking changes of pin-project are much less likely than pin-project-lite, we won't have to release tracing-futures patches just to bump the pin-project dependency nearly as often — and it reduces the potential for multiple pin-project versions in users' dependency trees.

As for pin-project-lite, 0.3 release may be needed soon. (Using pin-project-lite in core crate requires breaking changes.)
As for pin-project, 2.0 will not be released unless a year has passed since GAT was stable. (Actually, I think we can support GAT as an option, so breaking changes are not always necessary.)
That said, pin-project-lite is very light, so I don't think multiple pin-project-lite versions in dependency trees will have an impact on compile time.

[jplatte]

Bump!

Hyper has now been on pin-project-lite for a while after the initial regression was fixed (hyperium/hyper#2566). Otherwise nothing has changed AFAIK.

[davidbarsky]

Sorry for the delay—if Hyper switched over, might as well switch over here.

[davidbarsky]

I'll merge once CI passes.