Remove `mvbox_move` and `only_fetch_mvbox` options

[link2xt]

These two options are "legacy options" that exist to support "shared mailbox" usage similar to "show_emails" (#7631).

We currently have no plan on how we want to remove these options. We need a migration plan for two cases: mvbox_move=1, only_fetch_mvbox=0 and only_fetch_mvbox=1.

In case of mvbox_move=1 and only_fetch_mvbox=0 we can probably add a device message warning about the upcoming change and then turn off the option. If by this time we already solve #7631 somehow, then the user can solve the problem of cluttered inbox by adding a second relay and migrating there.

For only_fetch_mvbox=1 it is a bit more complicated as it is used to support the "alias" usecase, see here: https://support.delta.chat/t/it-may-be-unobvious-that-the-deltachat-folder-use-case-is-going-away/4495
If we want to support this for servers where user has access to configuring an alias and adding a sieve filter that moves messages with Delivered-To set to this alias to a separate folder, we can make a per-transport option "folder" and just run the inbox loop on this folder.
I am looking at the current implementation of only_fetch_mvbox and it seems to be very hacky: we still maintain connection to the inbox, but then should_ignore_folder returns false for the inbox and it is ignored.

Rough plan:

1. Add device message for users with mvbox_move=1 and only_fetch_mvbox=0 that the option is deprecated. Not as a migration, just somewhere after opening the database or in housekeeping or so.
2. Maybe one release later: turn mvbox_move=0 off and remove all the code that allows running multiple IMAP connections. Instead run a single IMAP loop, either on the Inbox or on "DeltaChat" folder if only_fetch_mvbox=1 is on. At this point users still cannot add second relay if only_fetch_mvbox=1 is on.
3. Turn only_fetch_mvbox into a "folder" option in the advanced settings of the relay. Maybe make it unchangable in the UI so users cannot configure new relays in such a way, but code-wise it is probably not a big deal to support.

[ell1e]

Maybe make it unchangable in the UI so users cannot configure new relays in such a way, but code-wise it is probably not a big deal to support.

Not saying this is needed, but I'm curious: if this path were to be taken, would this mean for initial classic mail account creation the option would remain available? And just for any additional relays added for redundancy, it wouldn't be?

[adbenitez]

Turn only_fetch_mvbox into a "folder" option in the advanced settings of the relay. Maybe make it unchangable in the UI so users cannot configure new relays in such a way, but code-wise it is probably not a big deal to support.

how do you expect error messages to be received if only a folder is watched? this maybe might for some alias use case but not for others without alias, and I don't think it is worth a dedicated option, we want to get rid of options not to add new ones, and absolutely not to have special exceptions and "ah you are one of those legacy users that has special secret option X" in 5 years

[ell1e]

Because "Move to ..." will be removed, I don't think you'll be able to use it without an alias.

I don't think it is worth a dedicated option,

I would totally understand if it ended up being removed.

[iequidoo]

I think we need a per-relay only_fetch_mvbox anyway to allow users migrate from such setups to chatmail or another "normal" setup (for which INBOX is fetched).

[r10s]

we should remove only_fetch_mvbox alltogether as well.

it will break some useless, but that's a rarely used option anyways, as always needing server-side support, it was mainly used by super-advanced users, most of them probably from our circles. the option was added for a single nerdy request, btw.

it is a pity for these users - but maintaining it forever will cost much resources, discussions, and raise issues as the already mentioned "error" case that will not work - or again raise the incentive to watch multiple folders. it is also inconsequent wrt shared usage which we do not want to support. let's better be consequent here.

fully agree with the device message, showing impact and possible mitigations.

timing wise, it is also fine. it is better to remove the "shared options" altogether now, instead of paving some, again temporarily, solutions, adding UI changes and bugs and whatnot.

in german, there is a saying "Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende" ("Better an end with horror than horror without end") -- but again, most user will be affected and annoyed by removal of mvbox_move - only_fetch_mvbox is only our nerdy circled

[ell1e]

There seems to be still a lacking migration path for some users, see discussion here.

One other way to allow them migrate would be to bring back moving to a different email address as a whole, like used to be possible. (That is, replace all current relays and addresses with an entirely new one but while bringing along the identity, without relying on the "Add Relay" dialog.)

[link2xt]

how do you expect error messages to be received if only a folder is watched?

If messages are moved to a separate folder based on Delivered-To header, then NDNs are delivered in the same folder too.

and raise issues as the already mentioned "error" case that will not work - or again raise the incentive to watch multiple folders

So this is wrong, there is no need to watch multiple folders.

[r10s]

k, this was a bad example, NDN do not need multiple folders to be watched when Delivered-To is used. but not all go that way, ppl are using what works at a first glance, and that will result into issues then, and we will have to deal with them, if we offer some option there.

but we really do no longer want to deal with that, to free some brain areas (obviously it is required) for other things, but also as it is against "no shared mailbox" allowed. also, i strongly doubt many ppl are really using, justifying lots of effort going into that

also, seems there is a migration path, https://support.delta.chat/t/it-may-be-unobvious-that-the-deltachat-folder-use-case-is-going-away/4495/19 , so effort should go into making that a somehow clear description that goes to a device message

again, more users will be affected by removal of mvbox_move, both need a migration path

[link2xt]

Next step for this is #7651