[feature](brpc) Support TLS certificate hot reload

[Yukang-Lian]

Problem

The vendored BRPC 1.4 TLS server cannot reload its default certificate and private key after startup. Certificate rotation therefore requires rebuilding the server-side TLS context, and encrypted private keys also need to be propagated into BRPC.

Changes

• Add opt-in BRPC server certificate hot reload with a configurable refresh interval.
• Watch certificate, key, and CA files and retry a reload when a transient partial update fails.
• Support password-protected private keys on the OpenSSL server and client paths.
• Fully configure a replacement SSL_CTX before publishing it.
• Serialize context acquisition/replacement so SSL_new and SSL_set_SSL_CTX take an OpenSSL reference before the old owner reference is released.
• Explicitly reject encrypted private keys on MesaLink instead of referencing OpenSSL-only helpers.
• Add concurrent certificate-rotation and new-handshake/RPC coverage.

The final brpc-zzzz-* patch intentionally follows the historical hot-reload backport in the existing brpc-* patch order. It replaces the original delayed-free/atomic-cast approach with the reference-counted, locked handoff described above.

Validation

• Replayed all 20 brpc-* patches, in the same order used by download-thirdparty.sh, onto a fresh BRPC 1.4.0 tree: no rejects.
• Built both brpc-static and brpc-shared with OpenSSL 1.1.1s.
• SSLTest.ssl_reload: passed.
• SSLTest.hot_reload_default_certificate_during_handshakes: passed; it performs 20 certificate swaps while a background thread repeatedly creates short TLS connections and executes RPCs.

Known limits

• Hot reload replaces the default context; it does not rebuild SAN/SNI filter mappings for newly introduced names.
• File detection uses second-resolution st_mtime.
• This PR provides the vendored BRPC capability; individual Doris servers still need to opt in through ServerOptions.

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?