[WIP] WiFiClientSecure: make functions for certificate verification more consistent

[igrr]

Currently WiFiClientSecure has two ways to verify that the remote server is using an expected certificate:

• verify(fingerprint, hostname), which compares SHA1 fingerprint of the server certificate to a known value, and
• setCACert/loadCACert + verifyCertChain, which checks the certificate chain, given the root certificate.

This PR attempts to make all ways of verification follow the same pattern:

1. set verification data using one of WiFiClientSecure methods (setCACert, setFingerprint, setSPKI, allowSelfSignedCerts)
2. call verifyCertChain, which checks that the certificate chain is valid, and uses the strongest of the previously set methods to verify.

This approach makes it possible to use WiFiClientSecure methods (setCACert, setFingerprint, setSPKI, allowSelfSignedCerts) together with HTTPClient: first call HTTPClient::begin, then set verification method on the underlying WiFiClientSecure, then call HTTPClient::GET or POST to connect and issue the request. Internally, that calls WiFiClientSecure::verifyCertChain once the connection is established.

This PR also adds verification using subjectPublicKeyInfo (SPKI), which was present in axTLS-8266 for a while now. SPKI is a SHA256 hash of the public key, and it doesn't change as often as the certificates are reissued, hence may require less often updates compared to SHA1 fingerprint of the certifiacate.

Currently WIP as only WiFiClientSecure changes are in place.

• update WiFiClientSecure examples, demonstrate various ways to verify the certificate
• change signatures of begin functions in HTTPClient, add explicit functions to use TLS support
• refactor verification flow in HTTPClient to match the new approach
• update HTTPClient examples
• update docs

[proppy]

I wonder if it wouldn't be "simpler" for HTTPClient to take an already connected Arduino Client interface and delegate the connection/cerficate/loading/verification to WiFiClientSecure initialization.

@igrr what do you think?

[igrr]

Thanks @proppy, that sounds like a nice approach. The only thing that HTTPClient currently adds on top (which won't be possible in the approach you have described) is parsing of URL into protocol/host/port/URI and calling WiFiClient[Secure].begin(host, port). I think we can add a new overload to HTTPClient::begin which takes Client as an argument, assuming that it is already connected and ready to be used.
And in this case we also need to pass host name to HTTPClient so it can set corresponding HTTP header.

[devyte]

@earlephilhower does this make sense in view of the new bearssl implementation?

[earlephilhower]

With axtls on the way out, and the use cases described here available already thanks to HTTPClient updates and BSSL, I think this is pretty well obsoleted. Closing.