properly isolate FFI online tests (avoid caching) and reconnect on direct-imap failures

[hpk42]

two commits to fix two test flakyness sources (EDIT: and one cleanup commit removing all caching-related logic from the FFI test plugin).

1. (EDIT) When account addresses are reused across tests, unexpected events or un-drained messages from previous setup steps/test runs arrive can cause assertion failures. I think it's fine to just create new addresses on CI all the time. Creating 100-200 addresses per test run is worth the guaranteed isolation. Ultimately Postfix on the CI server is free to arbitrary delay messages between mailboxes, and re-using them randomly breaks test isoilation. Better to exclude this failure mode cleanly and avoid caching. RPC-tests also use no caching.

2. under parallel test load transient socket resets during directimap SSL setup can crash tests during fixture initialization example: :

______________________ test_message_override_sender_name _______________________
[gw5] darwin -- Python 3.10.16 /Users/runner/work/core/core/python/.tox/py/bin/python

    def test_message_override_sender_name(acfactory, lp):
>       ac1, ac2 = acfactory.get_online_accounts(2)

tests/test_1_online.py:448: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
.tox/py/lib/pypy3.10/site-packages/deltachat/testplugin.py:370: in init_imap
    acc.direct_imap = DirectImap(acc)
.tox/py/lib/pypy3.10/site-packages/deltachat/direct_imap.py:45: in connect
    self.conn = MailBox(host, port, ssl_context=ssl.create_default_context())
...
../../../../hostedtoolcache/PyPy/3.10.16/arm64/lib/pypy3.10/_cffi_ssl/_stdssl/__init__.py:550:
>           raise pyssl_error(self, ret)
E           ConnectionResetError: [Errno 54] Connection reset by peer

Just retrying imap connect (like core does itself) is fine.

[link2xt]

First example https://github.com/chatmail/core/actions/runs/30563560871/job/90944100948#step:9:315 is in deltachat-rpc-client tests, but the commit (and the whole PR) is changing legacy python tests. There is no caching in deltachat-rpc-client already, so test_no_markseen_in_team_profile failed for some other reason. I think it was actually this already closed issue: #8446

[hpk42]

First example https://github.com/chatmail/core/actions/runs/30563560871/job/90944100948#step:9:315 is in deltachat-rpc-client tests, but the commit (and the whole PR) is changing legacy python tests. There is no caching in deltachat-rpc-client already, so test_no_markseen_in_team_profile failed for some other reason. I think it was actually this already closed issue: #8446

fair enough. But if rpc-tests already do no caching, all the more reason the remove it from FFI based tests as well. I edited the PR description accordingly. Removing the caching actually removes >100 LOCs from the test support code.

[link2xt]

https://docs.python.org/3/library/ssl.html#ssl.SSLError says ssl.SSLError is a subtype of OSError, so if OSError is catched, then there is no need to catch ssl.SSLError as well. Maybe even catch only ConnectionError.

IMAP errors probably should not be ignored, if we managed to connect and IMAP server says e.g. that we cannot login (because the test server has registration disabled, possibly automatically), then retrying forever will likely not help.

[hpk42]

changed it to OSError, IMAP4.abort with a comment.

[link2xt]

There was also an attempt to remove caching at #5446, apparently reusing the databases saved some time on configuration (requesting autoconfig, logging in with a test session just to add transport), but all the message cleanup with key reuse is likely not worth it.

[hpk42]

some measurements for running standard tox CFFI test suite:

• fastest branch runs against fasted main: 28s - 29s, so maybe 4% slower
• slowest branch runs against slowest mains: 49s-53s (but main had more of them)

it seems runs falls into one of the buckets. pytest durations says test_send_lots_of_offline_msgs sometimes spends 30s in teardown and that probably comes from scheduler.rs' let timeout_duration = std::time::Duration::from_secs(30); while an SMTP connection is in flight and teardown happens.

all in all the branch should not be noticably slower. running core tests against lxc containers should be noticeably faster, see #7926