Cancel results for user automatically

[andyundso]

Relates to #539

FreeTDS enforces a strict sequence of how queries are sent and results are retrieved. To summarize it very briefly:

• Open a connection using dbopen.
• Prepare a command buffer using dbcmd.
• Send it to the server using dbsqlsend.
• Acknowledge that the server acknowledge using dbsqlok.
• Gather metadata using dbdbresults.
• Fetch each row using dbnextrow or cancel the running results (dbcancel)
• Close the client using dbclose if not cancelled.

You do not have to serialize / bind each retrieved result, but you still need to fetch them. This is mentioned in the sample code as well:

DB-Library doesn't insist every column — or even any column — be bound or otherwise retrieved into the application's variables. There is, however, one absolutely crucial, inflexible, unalterable requirement: the application must process all rows produced by the query.

The current implementation of do and insert perform the entire sequence. However, each works different: Since each lazy-loads each result from the server, it cannot perform the entire sequence as we do not want to fetch all results at once and the user is free to cancel the iterator early.

As mentioned on #539, the error Assertion conn->in_net_tds == NULL' likely occured when people did not call cancel on the result object, as the query is technically still pending from FreeTDS point-of-view.

FreeTDS also mentions:

Before the DBPROCESS can be used for another query, the application must either fetch all rows, or cancel the results and receive an acknowledgement from the server.

With this PR, in #execute, I check if we have to still acknowledge and fetch results prior to running another query, essentially doing the job of cancel automatically for the user.

This is not my initially proposed solution on #539. I have coded out that proposed solution as well in a different branch, but during that development, I imagined that people could run into issues when a query will produce a large result set. But it helped me to understand the request lifecycle of FreeTDS better in order to develop this solution.

[andyundso]

@aharpervc even if I am still waiting for a reply on the original issue, I think this PR is good to have look.