DTLS should silently drop messages with invalid MAC instead of sending fatal alert

According to RFC 9147 4.5.2. Handling Invalid Records:

Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. Implementations which choose to generate an alert instead MUST generate fatal alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to DoS attacks because UDP forgery is so easy. Thus, generating fatal alerts is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties.

With the current behavior I'm having issues with a use case of repeated connections on the same ports. It looks like Application Data messages that arrived from the client on the previous connection are buffered and handled after the new connection's handshake, possibly due to #20597. Since these Application Data messages are handled as part of a different connection, their MAC validation fails, which generates a fatal alert on ssl/record/methods/dtls_meth.c:173. I confirmed that removing the fatal alert fixes the issue I'm facing - the buffered messages from the previous connection are silently dropped. This is the recommendation from the RFC. I'll open a PR for the fix, please tell me if it's acceptable