Support SASL-IR for all AUTHENTICATE mechanisms

[maneesha-xyz]

Feature Request

Summary

Support SASL-IR for all AUTHENTICATE mechanisms: let the client send an initial response inline on the AUTHENTICATE <mech> <initial-response> line, skipping the + continuation round-trip.

Why is this feature needed?

• AUTHENTICATE PLAIN currently always sends a + continuation and blocks on a second read. It ignores any initial response the client appends inline. OAUTHBEARER/XOAUTH2 already accept an inline initial response, so behavior is inconsistent across mechanisms.
• SASL-IR capability is only advertised when oauthSASLReady (OAuth configured), so it's never advertised for plain TLS-only setups, even though that's the exact case IR support would need to cover for PLAIN.
• Clients that support SASL-IR expect the capability advertised whenever an AUTH mechanism supports it, and may send IR regardless, causing broken exchanges against the current PLAIN path. Nextcloud Mail specifically uses SASL-IR for its IMAP login.
• Saves one network round-trip per login, meaningful for high-latency mobile clients.

Alternatives Considered

• Leaving PLAIN without IR support was rejected: it's inconsistent across mechanisms and non-conformant with RFC 4959 once any mechanism advertises it.

Additional Context

• RFC 4959: https://www.rfc-editor.org/rfc/rfc4959
• Relevant code: internal/server/auth/auth.go, functions buildCapabilities and HandleAuthenticate (PLAIN, OAUTHBEARER/XOAUTH2 branches)
• Acceptance criteria:
  • SASL-IR advertised in CAPABILITY whenever TLS is active (not gated on OAuth config)
  • AUTHENTICATE PLAIN <IR> skips the + continuation, matching existing XOAUTH2/OAUTHBEARER IR behavior
  • Missing/empty IR still falls back to continuation prompt for all mechanisms
  • * cancellation still honored in all paths
  • Tests cover IR present vs. absent for each mechanism