Handling incomplete certificate chains in Node TLS

### What is the problem this feature will solve? Servers should return a complete certificate chain, which can be validated up to a trusted root. Sadly, some don't, and instead return a chain that references an intermediate cert signed by a trusted root, but doesn't actually include the intermediate. There's also possible cases where an intermediate cert expires, and the authority has reissued a new intermediate with the same key, but the chain only contains the old intermediate. There's a test site for this here: https://incomplete-chain.badssl.com/. You can open this in your browser just fine, but in Node: ```js > require('https').request('https://incomplete-chain.badssl.com/') ... Uncaught Error: unable to verify the first certificate at TLSSocket.onConnectSecure (node:_tls_wrap:1679:34) at TLSSocket.emit (node:events:518:28) at TLSSocket.emit (node:domain:552:15) at TLSSocket._finishInit (node:_tls_wrap:1078:8) at ssl.onhandshakedone (node:_tls_wrap:864:12) at TLSWrap.callbackTrampoline (node:internal/async_hooks:130:17) { code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE', ``` Incomplete chains like this are bad behaviour, but it's also more common than you'd think, because it works in most places. More specifically: all modern browsers (Chrome, Edge, Safari, FF) and Mac/Windows OS libraries (Secure Transport & schannel) all seem to handle this automatically. These missing intermediates are generally handled with one a few different approaches: * Caching intermediate certs seen elsewhere, so you can validate any subsequent certificates that reference this intermediate, even if they don't include it. * Reading Authority Information Access (AIA) metadata from the certificates that are provided, to dynamically fetch missing intermediate certs when required. * Preloading commonly used intermediates directly - effectively starting with a complete cache. AFAICT Secure Transport (macOS), schannel (Windows), Chrome, Edge & Safari all use AIA fetching to …