Fix connection secure port management.

[stankudrow]

Fix errors in the connection security parameter + minor (un)related corrections

This PR was inspired by #138, and I thought it would be a good idea to split the secure connection case and query parametrisation, focusing only on the first part. It wasn't straightforward, but perhaps that's for the best.

@barakor, I hope I'm not stepping on your toes — I fully acknowledge your contribution. I'd appreciate it if you could also review this PR; your suggestions will be greatly appreciated and carefully addressed.

Some tests used to fail due to issues with parameter substitution processing (related to #147). @baconfield, @dmkulazhenko, could you please review these changes?

I experimented with configuring connections in the tests, which caused tests using a bare Connection() or Pool(...) without connection_kwargs to fail. This is actually a positive outcome, as it revealed the fragility of those tests.

@long2ice, @nils-borrmann-tacto, @DaniilAnichin, I had some difficulty specifying the pytest-asyncio asyncio_default_fixture_loop_scope attribute and addressing the warning from pytest: neither the "session" nor the "function" scope resolves the issue. By the way, your reviews would be very welcome.

[stankudrow]

@baconfield . @nils-borrmann-tacto , @long2ice , damn, this PR should go first because the failed CI in the dev - https://github.com/long2ice/asynch/actions/runs/27552079391/job/81440866403 . @barakor, @dmkulazhenko , @DaniilAnichin , @pohmelie, please help with reviews.

[DaniilAnichin]

Seems to be ok; about the pytest-asyncio: mostly I've dealt with it by switching to anyio, but I don't think this is a PR to do it in.

[stankudrow]

Seems to be ok; about the pytest-asyncio: mostly I've dealt with it by switching to anyio, but I don't think this is a PR to do it in.

Yeah, you are right, this PR is not about anyio. However, before proposing a PR, feel free to open an issue and lay out pros and cons of anyio, examples etc.

[barakor]

Seems ok overall, but the change in asynch/connection.py that I commented about is problematic

[baconfield]

@baconfield . @nils-borrmann-tacto , @long2ice , damn, this PR should go first because the failed CI in the dev - https://github.com/long2ice/asynch/actions/runs/27552079391/job/81440866403 . @barakor, @dmkulazhenko , @DaniilAnichin , @pohmelie, please help with reviews.

Resolved with #163

[stankudrow]

@baconfield . @nils-borrmann-tacto , @long2ice , damn, this PR should go first because the failed CI in the dev - https://github.com/long2ice/asynch/actions/runs/27552079391/job/81440866403 . @barakor, @dmkulazhenko , @DaniilAnichin , @pohmelie, please help with reviews.

Resolved with #163

The changes from the #163 were here before - https://github.com/long2ice/asynch/pull/162/changes#diff-94026d54d9ecff66c0362322fe026b6995eb0bdbb56bb8bf84447fc7fa148b04 . You can close the #163 PR.

[stankudrow]

@DaniilAnichin , @pohmelie , hello.

In spite of these changes, could you re-review and re-approve them in case they are really OK? After that this PR can go to the final-boss review. Sorry for these bureaucratic troubles.

[stankudrow]

@long2ice , hello.

This PR seems to be "mergeable".