Create copy_buf_abortable, which enables to stop copying in the middle.

[kazuki0824]

See #2497 .

Summary

When transferring data from one place to another using the copy_buf function, you may want to abort the operation in the middle of the transfer, for example, by SIGINT. Since the transfer is divided into small increments by internal buffers and probably must not be done at a time, the interruption logic can be implemented by checking for the aborting request flag at every poll_fill_buf().

This patch has

• a new func and struct that is like CopyBuf and has a new behaviour, similar to what futures::abortable::Abortable does.
• changes of visibility of some Abortable-related private members, such as AbortInner and its children.

[kazuki0824]

Motivation

If we read file with futures_io and make it abortable, we have to

1. open std::fs::File struct by futures::io::BufReader,
2. into_stream
3. make it abortable by Abortable::new(file).
   In addition, if we want to perform copying, then we have to
4. into_async_read()
5. futures::io::copy().
   (Here, we have to use AsyncRead instead of stream::Abortable. If you deal with character devices or sockets, there is no guarantee that the size of the file is limited to a constant value. Since forward() in futures::stream reads all, and then write all, the approach cannot be applied.)
   It sounds very redundant to me. So it should be better to add a new abortable variant of copy() and copy_buf().

Recap of recent discussion in #2497

@taiki-e pointed out that

* Is it possible to do this same thing by implementing AsyncRead/AsyncWrite for Abortable? If so, that would be more generic and preferable.

I also think that for more convenience, something like AsyncRead / AsyncWrite 'd abortable is necessary. I agree to you at this point. (also mentioned in #2156)
But IMHO simply implementing Async io on an existing stream::Abortable may cause inconvenience in the case such as copying.

Pros and cons

I think there exist 2 different options,

1. Add a new struct AbortableCopyBuf<T: AsyncRead> , method copy_buf_abortable(inner) (My current PR, as per @taiki-e 's suggestion)
2. Implement AsyncRead, AsyncWrite on stream::Abortable<T: AsRef<[u8]>>(@taiki-e suggested)

For first one, we perform copy with futures_io and make it abortable, we have to

1. open std::fs::File struct by futures::io::BufReader,
2. futures::io::copy_buf_abortable().

But the second one,

1. open std::fs::File struct by futures::io::BufReader,
2. into_stream
3. make it abortable by Abortable::new(file).
4. directly pass the abortable stream to futures::io::copy()

So I think the second one has a thicker struct that perhaps lowers performance, and the first one is less complicated for programmers when it comes to copying one to another.
Consequently, I think it is a bit hard to realize copy() by simply adding AsyncRead/AsyncWrite to Abortable.

Thus, I believe that implement abortable copy into a separate mod, like this current PR, is better off.

[kazuki0824]

@taiki-e After that, I found an opinion that we should implement the ability to stop in the middle for all IOs, not just the copy_buf(). This topic is very relevant to this pull request, but the original Issue is already outdated. Therefore, I created a new issue in #2509, and then suggested another solution. Please check it out.
To me, the method I suggested in #2509 is more generic(and based on your suggestion!), but I feel it will be very very complex, costful to implement the future work if we aim to implement abortable feature on any readers/writers, not only a copying op.

[kazuki0824]

@taiki-e Sorry for the late response. I saw through your review and added another change in this PR.

[taiki-e]

Thanks, looks good to me aside from a nit.