Initial implementation of get_all() for async using Stream

[phayes]

This is an initial implementation of List::get_all() for async using Stream.

It needs testing, but I think the general approach is correct. I'll make a note when I feel like I've tested it enough for merging.

Once tested and merged, this will resolve #41

[arlyon]

This is great, thanks for the work here. Only suggestion is to reduce nesting in the unfold:

pub fn get_all(self, client: &Client) -> impl TryStream<Ok = T, Error = Error> {
    // We are going to be popping items off the end of the list, so we need to reverse it.
    let mut init_list = self;
    init_list.data.reverse();

    futures_util::stream::unfold(Some((init_list, client.clone())), |state| async move {
        let (mut list, client) = state?; // if none, we sent the last item in the list last iteration
        let val = list.data.pop()?; // the initial list was empty, so we're done.

        if !list.data.is_empty() {
            return Some((Ok(val), Some((list, client)))); // some value on this page that isn't the last value on the page
        }

        if !list.has_more {
            return Some((Ok(val), None)); // final value of the stream, no errors
        }

        match list.next(&client).await {
            Ok(mut next_list) => {
                next_list.data.reverse();

                // Yield last value of this page, the next page (and client) becomes the state
                Some((Ok(val), Some((next_list, client))))
            }
            Err(e) => Some((Err(e), None)), // we ran into an error. the last value of the stream will be the error.
        }
    })
}

Otherwise, thanks for the contribution! Are you going to keep both PRs up or close this one in favour of #194?

[phayes]

Thanks for the improvements @arlyon .

I've now tested this enough to satisfy myself that it's correct and is ready for merging.

@arlyon , as to your question, I created a separate PR since this PR is a lot smaller than #194. The other PR also contains these changes, but also includes far more invasive changes that might require more careful review. So it might make sense to review and merge this PR first if you're happy with it, then merge #194 after you've had the time to review the more complex changes there.

Or you could just merge #194 and be done with it all. :)

[arlyon]

Agreed, I'll merge and then you can rebase. Thanks for the contribution!

[phayes]

Thanks @arlyon ! #194 has been rebased and is ready as well.