Next item feature (Fixes #121)

[IvanChepurnyi]

NextItem type adds distinction between empty result set and just end of
the result set that had rows previously.

• Introduced ResultSetMetaState to distinguish between fetched row and not
  fetched yet result
• Introduced NextItem to return back EmptyResult with columns that are
  impossible to fetch if next is called instead

[IvanChepurnyi]

This pull request fixes #121

[blackbeam]

Hi. Sorry for the delay.

I've looked through your PR and it turns out that it didn't fix #121. It might be the case that our understanding of the problem is a bit different, so let me describe it from my point of view:

#121 correctly states the problem: empty result sets in a multi-result set are skipped by the result set iterator.
The consequence of this is that you can't read metadata of a result set if this result set contains no rows and is in the middle of a multi-result set. In other words, the following test will fail but should pass:

#[tokio::test]
async fn should_provide_multiresult_set_metadata() -> super::Result<()> {
    let mut c = Conn::new(get_opts()).await?;
    c.query_drop("CREATE TEMPORARY TABLE tmp (id INT, foo TEXT)")
        .await?;

    let mut result = c
        .query_iter("SELECT 1; SELECT id, foo FROM tmp WHERE 1 = 2; DO 42; SELECT 2;")
        .await?;
    assert_eq!(result.columns().map(|x| x.len()).unwrap_or_default(), 1);

    result.for_each(drop).await?;
    // the following assert will fail with 2 != 1, because next two sets will be skipped
    assert_eq!(result.columns().map(|x| x.len()).unwrap_or_default(), 2);

    result.for_each(drop).await?;
    assert_eq!(result.columns().map(|x| x.len()).unwrap_or_default(), 0);

    result.for_each(drop).await?;
    assert_eq!(result.columns().map(|x| x.len()).unwrap_or_default(), 1);

    c.disconnect().await?;
    Ok(())
}

I have a lightweight solution in #123, that, i believe, should work for you. Could you please look into it?

[IvanChepurnyi]

Thanks, I'll check if it is going to fix my use case with MySQL proxy. I think you can close this PR then, if I find an issue with the current implementation, I'll open PR for the adjusted behaviour.