fix(webrtc): Choose the SRTP profile by the server's order, AEAD first
RFC 8827 section 6.5 has WebRTC implementations support
SRTP_AES128_CM_HMAC_SHA1_80 (MUST) and favor AEAD over non-AEAD suites
(SHOULD). The server offers AES-256-GCM, AES-128-GCM, then SHA1_80, but
rtc-dtls took the first profile of the client's list it supports, and
Chromium lists SHA1_80 ahead of its GCM profiles (prefer_gcm_crypto_suites
is off by default): Chromium and Edge sessions ran SHA1_80 while Firefox,
listing GCM first, ran GCM. The server's order decides among the profiles
both sides offer: a client offering GCM gets AES-256-GCM, one offering
only SHA1_80 still gets it.
Sealing a 1200-byte packet in place takes 0.32 us under AES-256/128-GCM
against 1.12 us under SHA1_80 (bench_protect_rtp, release); the GCM tag
is 6 bytes longer, inside PACKET_MAX's headroom. rtc-dtls's
tests/srtp_profile_choice.rs drives the handshake (two of its three cases
fail on the client's order), and rtc-dtls-selkies.patch is regenerated.
Chromium's sessions in the suites negotiate SRTP_AEAD_AES_256_GCM;
selkies-rtc's tests, test_matrix webrtc, test_webrtc_cut (Chromium,
Firefox), test_signaling_roles, test_media_on_start, test_regressions
pacer, test_two_displays, test_operator_api, test_multi_controller
visible-wr, test_webrtc_loss_recovery, and test_slow_page webrtc
(Chromium, Firefox, Wayland, 10/10 each, as the client's order) pass.