feat: Add `close_notify` graceful shutdown API

[HMBSbige]

Summary

dimpl currently has no way for the application to initiate a graceful connection closure. The DTLS standards (RFC 9147 §5.10, RFC 8446 §6.1) define close_notify as the mechanism for this, and while dimpl can receive a close_notify alert, it cannot send one.

Background

Per RFC 8446 §6.1:

Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert.

RFC 9147 §5.10 inherits this requirement with important caveats for unreliable transport:

• Alerts are not retransmitted
• Implementations SHOULD NOT depend on receiving alerts to signal connection closure
• Data ordering after closure uses epoch/sequence number, not receipt order

This makes close_notify a best-effort, fire-and-forget signal — but it is still a MUST-level requirement to send before closing the write side.

Current state

• Receiving: DTLS 1.3 handles incoming close_notify in engine.rs by returning Error::SecurityError. DTLS 1.2 silently discards alerts.
• Sending: No public API exists. There is no close() or shutdown() method on Dtls.
• Tests: dtls13_close_notify_graceful_shutdown and dtls12_close_notify_graceful_shutdown in tests/*/edge.rs document this gap.

Proposed changes

1. Add a close(&mut self) method to Dtls that queues a close_notify alert for transmission
2. After close() is called, poll_output should yield the alert packet, then signal that the connection is closed
3. The alert MUST NOT be retransmitted (per RFC 9147 §5.10)
4. Distinguish between a clean closure (close_notify received) and an abrupt one (no alert) on the receiving side

[algesten]

This makes close_notify a best-effort, fire-and-forget signal — but it is still a MUST-level requirement to send before closing the write side.

Yeah, this is a know omission – both alert and close. In the WebRTC case in str0m, it doesn't make any sense. You'd just throw away the entire WebRTC stack instead of gracefully closing stuff.

That said, I have nothing against having this API. So PR welcome!