将AsyncDrop从AbortSafeFuture中拆分出来

[TOETOE55]

之前AbortSafeFuture中，poll和poll_cancel里面都需要有内存释放的逻辑。
可以单独抽离一个AsyncDrop trait来统一内存释放的逻辑。
而中断Future的逻辑也有AsyncDrop承担。

pub trait AbortSafeFuture: AsyncDrop {
    type Output;
    fn poll(self: Pin<&mut ManuallyDrop<Self>>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}

pub trait AsyncDrop {
    fn poll_drop(self: Pin<&mut ManuallyDrop<Self>>, cx: &mut Context<'_>) -> Poll<()>;
}

[TOETOE55]

我还没想明白的是：

1. AbortSafeFuture: AsyncDrop是否要加这个约束？感觉是需要的，现在rust不支持特化，没法为满足和不满足AsyncDrop的实现两套内存回收的逻辑。
2. poll_drop的签名是否是这个更合适？目前我们没法为Box<ManuallyDrop<Fut: AbortSafeFuture>>实现AbortSafeFuture

unsafe fn poll_drop(self: *mut self, cx: &mut Context) -> Poll<()>;

3. 为&mut ManuallyDrop<Fut: AbortSafeFuture>实现 AbortSafeFuture是否合理？其实现破坏了poll完inner future就要poll_drop的约定。另外这个约定是否必要？

[mu001999]

3 的话，感觉不需要严格约定到 AbortSafeFuture 的实现？我理解其实这些 blanket impl 算是实现的一部分，只约定 AbortSafeFuture 对外表现的行为是符合 poll 之后 poll_drop 的就行了（

[mu001999]

1 需要+1，poll 已经要求手动 drop = 跟 AsyncDrop 是绑定的；另外 AsyncDrop 有单独抽出来的必要吗（

[mu001999]

2 个人感觉不引入 unsafe 更好一点（

[TOETOE55]

另外 AsyncDrop 有单独抽出来的必要吗（

对于普通Future应该也能用这个trait，可以根据某个flag决定是否用AsyncDrop。

[mu001999]

另外 AsyncDrop 有单独抽出来的必要吗（

对于普通Future应该也能用这个trait，可以根据某个flag决定是否用AsyncDrop。

另外，AsyncDrop 的名字给人的感觉更像是异步的析构

[TOETOE55]

另外，AsyncDrop 的名字给人的感觉更像是异步的析构

确实就是。通过异步的析构来中断Future，而不是同步的析构

[mu001999]

另外，AsyncDrop 的名字给人的感觉更像是异步的析构

确实就是。通过异步的析构来中断Future，而不是同步的析构

我的意思是，AsyncDrop 更像是异步版本的 Drop，而事实上 AsyncDrop 其实只适用于 Future，或者可以叫 DelayedFutureDrop 之类的名字？

[TOETOE55]

而事实上 AsyncDrop 其实只适用于 Future

感觉有普适性？毕竟异步析构也是类这样的API，同时这里通过ManuallyDrop包裹了一下，实现了异步析构就不能安全地进行同步的析构了。