WIP: feat: add option to process unencrypted messages

[link2xt]

Closes #7494

Still don't know if the idea is to have the option per transport, or we just make it impossible to enable it with multi-transport.

Will need to enable it in tests that use unencrypted messages, and make sure it works for legacy vc-request somehow (by prefetching unencrypted Secure-Join header).

[r10s]

there are lots of discussions preventing to unblock this issue. i try to sum up the outcome, even tho i was not part of the most recent ones:

1. process_unencrypted should be per relay, not per profile
2. process_unencrypted is set to true for existing relays (maybe based on old show_emails) - gist is that nothing changes for them
3. for new relays, it will be false
4. several relays can have the option set independently, it is up to the user, to deal with the situation
5. the option will be hidden in "advanced / relay", UI-wise, it should not be worded as a feature ppl would enable without knowing much about it
6. as we cannot rely on process_unencrypted for "New Email" (otherwise, all existing profiles will get the option because of 2.) - we continue using is_chatmail for that for now

the last point, 6. still looks a bit tricky to me - i do not see a way to get rid of is_chatmail if we set process_unencrypted to true mostly unconditionally. maybe process_unencrypted at 2. should be set depending on existing is_chatmail. but i also was not part of all discussions, maybe this is clear already, then please comment. also correct the list above as needed :)

ftr, "New Email" is the only remaining function that relies on is_chatmail

[link2xt]

as we cannot rely on process_unencrypted for "New Email" (otherwise, all existing profiles will get the option because of 2.) - we continue using is_chatmail for that for now

We can turn "process unencrypted" off for relays that advertise XCHATMAIL automatically. And UIs can then show "new email" only if primary relay has "process unencrypted" enabled, which will be impossible to enable permanently then.