Connection Open with fast fail option

[David-Engel]

Putting this out there for consideration related to #29

Summary:
Implementing a programmatic way of overriding the behavior of SqlConnection.Open() to disable automatic connection retries in the event of transient errors. The transient error handling introduces a 10 second delay when used with default values. If an application is passing a connection object around and just wants to do a quick Open() availability check, they can pass SqlConnectionOverrides to Open() and disable transient fault handling logic.

I tried to apply the overrides to OpenAsync(), too. However OpenAsync() already seems to not apply transient fault handling and fails quickly and I was unable to change its behavior in a reasonable amount of time. Since the request was really only for Open(), I opted to not add the override option to OpenAsync(), too.

[David-Engel]

@saurabh500 - Thoughts on creating a new Open method for this?

For background, EF would like a programmatic way to fast-fail connection attempts (without modifying the connection string) in cases when they are just checking for the existence of a database (before creating one, for example). There does not seem to be a way to check for database existence without a connection. When the driver applies transient fault handling to connection attempts, it considers error 4060 (Cannot open database "%.*ls" requested by the login. The login failed.) a transient error since it could be an Azure connection reconfiguring the back end. Applying transient error handling adds a 10 second delay while the driver retries the connection when using the default connection properties. This results in a sub-par user experience while the user waits for SqlClient to fail.

FWIW, I'm not crazy about adding a new method to implement it like this. It's just one idea. Alternatives we've discussed include a new property on SqlConnection that can be set instead that would not necessarily be available via the connection string.

[cheenamalhotra]

1 option to consider is connection class APIs, keeping SqlConnection.Open() 'bool' parameter free for future standardization if needed at all.. since we inherit DbConnection.

We can design the new API such that it is understood as a temp flag, which when set only applies within it's scope. and does not reflect change in connection properties. Likewise we won't have to worry about pooling and connection property overriding.

e.g. SqlConnection.PauseConnectionResiliency() and SqlConnection.ResumeConnectionResiliency()
or SqlConnection.PauseConnectionRetries() and corresponding resume.

[saurabh500]

@David-Engel @cheenamalhotra I went through the issue and it looks like we definitely need a programmatic way of doing this, since the connection string may not be available if the SqlConnection Object is being passed around. I hadn't realized from our discussions on the call that SqlConnection instance is being passed around. In that case reconstructing the connection string from the connection object may not be possible. Let's discuss in the call tomorrow.

[cheenamalhotra]

LGTM