[release/8.0] Revert Azure SQL streaming breaking change

[AndriySvyryd]

Fixes #32052

Description

When the connection string points to an Azure SQL database we now by default configure a retrying execution strategy, per official recommendation. This in turn forces all the streaming queries to buffer (because we can't reliably retry a query if it fails in the middle of reading the results). This makes it a breaking change for apps that weren't using a retrying execution strategy as it increases the peak memory usage proportionally to the largest result set queried.

Customer impact

OutOfMemoryException thrown in some cases.

How found

Customer reported on RC2

Regression

Yes, from RC1.

Testing

Added tests.

Risk

Low.

[ErikEJ]

If you decide to implement this, there are more domains than .database.windows.net

[ErikEJ]

Does this mean that having a retrying strategy enabled always will require more memory?

[roji]

Does this mean that having a retrying strategy enabled always will require more memory?

@ErikEJ enabling a retrying strategy makes EF buffer the entire query resultset; this is required since if we stream, a failure could occur in the middle, and at that point retrying the query could yield different results (and user code has already started consuming the 1st resultset). There's a note about this in the performance docs.

Whether this requires (significantly) more memory really depends on the resultset size... With small resultsets, buffering should have (practically) zero overhead; but if you're loading a huge amount of data, this can obviously get very significant. Buffering basically means that memory overhead starts being proportional to the resultset size (whereas with streaming it is not).