Don't always clear rows being processed when non-recoverable error occurs

Currently if an exception occurs while processing rows we will clear those rows from internal memory and move on - which means those rows won't be processed again until the 60sec timeout has passed. But there are many transient errors - such as deadlocks - that can happen, and so clearing the rows in those cases just needlessly delays the processing of those rows.

It would be much better to try and determine if the exception that occurred was recoverable/transient, and if so not clear the rows from memory (instead just reprocessing them again).

Locate the row-processing and exception-handling path in the Azure Functions SQL extension, then inspect how rows are removed after failures. Check how transient errors such as deadlocks can be identified and how the existing retry or timeout behavior works. Done means recoverable errors retain rows for retry while non-recoverable errors continue to clear them; the issue names no files or tests.

Written by the indexing model from the issue text.