Use RFC 5465 IMAP NOTIFY to replace per-folder polling

Is your feature request related to a problem? Please describe.

Nextcloud Mail currently opens one IMAP connection per synchronised folder (see ImapToDbSynchronizer.php). On accounts with many folders — for example those using server-side SIEVE filters that sort incoming mail into tens or hundreds of sub-folders — this produces a burst of simultaneous IMAP authentications on every background sync cycle.

IMAP servers enforce a per-IP or per-user connection limit (Dovecot's default and Mailbox.org's enforced limit is 10 connections per user). With 60+ folders, every sync run immediately hits that limit and Dovecot rejects further connections:

NO [AUTHENTICATIONFAILED] Authentication failed: authentication failure
(Too many simultaneous connections.)

This renders Nextcloud Mail effectively unusable for accounts with more than ~10 subscribed folders unless the background sync interval is set to a very high value — which trades correctness for stability but means near-real-time sync is impossible.

This is a known problem also reported in:

• #10039 — Sync and Send NOT reusing connections for operations (open)
• #11240 — Synchronize all subscribed mailboxes in the frontend (open)

A related push-notification approach (webhooks) is tracked in #9855, but requires server-side infrastructure not available on hosted/external IMAP servers.

Describe the solution you'd like

Implement support for RFC 5465 – IMAP NOTIFY (RFC text).

A single authenticated IMAP connection can watch all subscribed folders simultaneously using:

NOTIFY SET (subscribed (MessageNew MessageExpunge FlagChange))

The server then pushes unsolicited responses for any matching event on any subscribed folder without the client having to poll. A single connection with periodic NOOP keepalives is sufficient to receive change notifications across the entire mailbox.

Benefits:

• Reduces concurrent IMAP connections from N (one per folder) to 1
• Makes sync push-based and event-driven instead of interval-based (lower latency, less server load)
• Completely eliminates the authentication-limit problem for accounts with many folders
• No server-side infrastructure changes required — works with any RFC 5465-compliant IMAP server

Detection: NOTIFY is a post-login capability on Dovecot-based servers — it does not appear in the pre-authentication CAPABILITY response. The check must happen after login, by inspecting the return value of a post-login CAPABILITY command directly.

Confirmed working servers: Dovecot ≥ 2.0, Mailbox.org, Cyrus, Gmail.

Describe alternatives you've considered

1. IMAP IDLE per folder — Keeps one persistent IDLE connection per folder. Still opens N connections; same root problem as the current polling approach.
2. goimapnotify / external IDLE daemon — Also uses one IDLE connection per folder; the connection count is identical. Not a solution for accounts with many folders.
3. Webhooks (#9855) — Requires the mail server operator to configure outbound webhooks, which is not available on hosted IMAP services such as Mailbox.org.
4. Reducing background sync interval — Reduces frequency but does not fix the connection burst; the problem re-occurs on every sync cycle.
5. External RFC 5465 NOTIFY bridge — A custom Python daemon using a single IMAP NOTIFY connection triggering occ mail:account:sync can work around the problem (confirmed against Mailbox.org/Dovecot), but requires manual deployment outside Nextcloud and is not an acceptable long-term solution for end users.

Additional context

• RFC 5465 NOTIFY is widely deployed and available on Mailbox.org, Gmail, and any server running Dovecot ≥ 2.0.
• Important implementation note: On Dovecot (including Mailbox.org), NOTIFY is only advertised after authentication. A pre-login CAPABILITY check will not find it. The post-login capability string on Mailbox.org includes: IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT … NOTIFY SPECIAL-USE FILTER=SIEVE …. The implementation must call CAPABILITY after login and use the returned string — not a cached pre-login value.
• Minimal fallback path: if NOTIFY is absent from post-login capabilities, fall back to the existing polling strategy.
• This would also complement #9855 by covering the common case (hosted IMAP without webhook support) without requiring any server-side changes.