fix: Respecting connection timeout in WiFiClientSecure

[vlastahajek]

Closes #5398

Using the same non-blocking socket connect pattern for respecting connection timeout, copied from WiFiClient::connect.

WiFiClient::connect uses lwip_connect_r, whereas start_ssl_client uses lwip_connect. I haven't found what is the difference between them. I tested both, both work ok, so I kept lwip_connect.

[CLAassistant]

All committers have signed the CLA.

[me-no-dev]

@david-cermak could you please have a look?

[david-cermak]

LGTM! Yes, the correct way of handling connection timeout is to set the socket to the non-blocking mode and select() on its writeability.

Some consistency comments:

• the code uses both lwip_... prefixed API (lwip-connect), as well as the standard posix like select() or close(). The former is faster, the latter is useful when writing generic code (e.g. with VFS), but in general better to stick to one API. On the other hand, this seems to be in line with the WiFiClient::connect, so it is consistent.
• lwip_connect_r() was an old re-entrant function variant in older IDF's, but in all currently supported versions, the socket API is fully reentrant and thread safe.
• As a side note: we typically switch the socket back to the blocking mode, after connect, so standard SO_RCVTIMEO and SO_SNDTIMEO options make sense, but this is in line with the previous code, as the socket was left in the non-blocking mode previously as well.