PR #541 released the GIL around SQLDriverConnect / SQLDisconnect /
SQLEndTran, but several SQLSetConnectAttr sites in connection.cpp
were left holding the GIL:

  - Connection::setAutocommit (SQL_ATTR_AUTOCOMMIT)
  - Connection::setAttribute (user-facing set_attr)
  - Connection::reset (SQL_ATTR_RESET_CONNECTION,
    SQL_ATTR_TXN_ISOLATION) — called by the pool on acquire.

setAutocommit is the call that hangs in the issue #565 repro: it
runs by default immediately after connect, and when the network
path goes through another Python thread (e.g. an in-process SSH
tunnel via paramiko + sshtunnel), that thread cannot make progress
while the GIL is held — deadlock.

Wrap each of these calls with py::gil_scoped_release, matching the
pattern PR #541 introduced for the other ODBC entry points.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Routes mssql_python.connect()+SELECT through a pure-Python TCP
forwarder running in a subprocess, with a hard external watchdog
(Popen.communicate(timeout=...)).

The forwarder's _pipe loop calls dst.sendall(...) on every chunk;
that bound-method dispatch needs the GIL, which is exactly the
deadlock condition from issue #565: with the GIL held across
SQLSetConnectAttr(SQL_ATTR_AUTOCOMMIT), the forwarder thread
cannot run, the driver waits forever for a reply, and the
subprocess hangs.

Verified that the test fails (in 30s, with the issue-#565 diagnostic
message) against the unfixed binary on main, and passes (~0.2s)
once the GIL release on setAutocommit/setAttribute/reset is in place.

Linux-only and runs in the default functional suite (not stress).
A subprocess + external watchdog is required because once the
worker thread deadlocks while holding the GIL, the entire Python
interpreter is starved — an in-process watchdog thread cannot
make progress either.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>