refactor!: remove configured_addr config

[link2xt]

configured_addr was already not used by real SMTP code.
Rust tests which emulate sending with TestContext.pop_sent_msg()
now have a way to set the "sending" address manually in memory.

Closes #8572

[link2xt]

@pbuzdin please create a separate account for your bot and don't let it post any comments in any chatmail or deltachat organization repositories. There are some community standards at https://delta.chat/en/community-standards, but even if they were not written down, it should be obvious that it is not great to run a bot that posts comments here pretending to be a human and then note that "a first-class preferred-transport concept has been requested there (comment 6090501441)" in pbuzdin/velta#114 (comment)

[pbuzdin]

That wasnt a bot comment. I wrote it myself because I'm having trouble using Deltachat in my region without manually selecting a relay for sending.

[r10s]

our idea for situation "one relay cannot send" is to improve sending failover. or, in the future, replacing that relay automatically.

adding more options, that most ppl would not understand, is often not a solution from our view. a configured_addr or used_for_sending were always meant as temporary things since we introduced multi relay. not having tons of options is also easier for us to debug and to get the model.

nerds detecting smth is wrong with a relay, by some log or so, can remove it.

as a general rule of thumb, we avoid options and beforehand questions whereever we can.

btw: the screenshots of velta look great!

[Hocuri]

• deltachat.h needs to be updated in order to remove the configured_addr reference.
• Changelog entry should be a bit clearer, in case people are still setting or getting this config, e.g. refactor: remove `configured_addr` config or even refactor!: remove `configured_addr` config

FTR:

• The configured_addr config which is removed in this PR was mainly used in tests, only very few places in the actual code still used it anymore
• This does keep get_primary_self_addr(), which might be renamed into get_any_self_addr() or get_some_self_addr() because there is nothing special about this addr anymore
• We still have the Addr config; we have been keeping it for bots that still set addr and mail_pw for configuration, but at some point we'll need to look for all bots that use it, make PRs to use a new API, and then remove the Addr config. (@link2xt correct me if I'm wrong)

[Hocuri]

I'm wondering if we should call this something like from_for_test_msgs, in order to make clear that it's only used in tests (which isn't obvious on all caller sites otherwise). But it's fine as-is, too.

[Hocuri]

This statement errors if there is no configured_addr. This means that a database created by a new Delta Chat can't be imported into an old Delta Chat.

Bumping DBVERSION would mean that we need coordinated releases on all platforms again, so, we likely want to avoid this. So, unless we find another solution, we likely have to keep some code that sets and updates configured_addr, and then remove it in some future version.

Concretely, after every transport mutation (e.g. save_transport, delete_transport, sync_transports), run INSERT OR REPLACE INTO config (keyname, value) SELECT 'configured_addr', addr FROM transports ORDER BY id LIMIT 1. Then add a test that creates a profile, deletes the first transport, and asserts the row points at an existing transport.

[link2xt]

I added a failing cross-core test now (test_cross_core.py::test_old_device_delete_transport). It sets up old second device and tries to delete a transport.

[link2xt]

Fixed it now by updating configured_addr with new transport::update_configured_addr in several places.

[Hocuri]

Could use list_transports()[0]["addr"] rather than removing this line, but it's fine as-is, too (same for the next removed line below)

[link2xt]

This is a CFFI test, so we don't have list_transports(), but i have added assert contact2.addr == ac_contact.get_self_contact().addr instead.

[Hocuri]

This test now doesn't test a lot anymore, it only does some very basic things:

• ac1 and ac1_clone is a multi-device profile
• ac1 adds a transport
• ac1 sends a message, the test doesn't control which transport is used for this
• Bob answers
• ac1_clone receives the answer

Until we have functional end-to-end tests that can control the network (i.e. a test that can block the first transport in order to ensure that the message is sent via the second transport), I guess we can't do much here, but we need to update the test name and comments. And then we need to make sure to quickly make functional bad-network tests possible, because right now we wouldn't notice any regressions in this area until DC is deployed.

[link2xt]

• We still have the Addr config; we have been keeping it for bots that still set addr and mail_pw for configuration, but at some point we'll need to look for all bots that use it, make PRs to use a new API, and then remove the Addr config.

We can also remove dc_configure() and configure() as a breaking change, then all users of this API will notice it does not exist anymore. But this is not for this PR.