Add SSL server examples

[AnthonyGrondin]

This PR add examples and bring changes needed to be able to use as a server.

TODO

Fix

• [x] Currently, this fails with MbedTlsError(-30592), (MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE) when a browser (or curl) displays a self-signed certificate error. I believe this should be fixed before merging this PR. This maybe has something to do with https://os.mbed.com/teams/sandbox/code/mbedtls/docs/tip/ssl_8h.html#a38ee2c1e3f232444df5ba3952d7ded33

Chores

• [x] Sync up with #8 when done
• [x] Add examples for esp32, esp32c3
• [x] Rename examples to be less confusing
• [x] Better document client_cert, client_key in the Certificates struct

[AnthonyGrondin]

After looking more into it, it looks like it would be up to the user to handle the self-signed error in the browser, as the connection is closed when it occurs.

There is also a bug with the async example, it seems to hang when the connection gets closed due to a self-signed certificate error. It doesn't return the correct res (-30592), it returns 0 so it goes into flushing data, but the connection is closed, so it hangs.

[bjoernQ]

Oh yes - probably the user just needs to choose to ignore the problem with the certificate or use command line wget/curl with the right options 👍

Regarding the async example: That definitely needs a fix then

[AnthonyGrondin]

I've renamed and added the missing examples. That was a very lengthy process. I think we should merge them together, and use features for the different arch, considering most of the examples are code duplication. It becomes very long to maintain when changing the public facing API.

All objectives I wanted to fulfill in this issue are done, but there's still this async error that should get fixed. I've documented extensively the Certificates struct, for usage in Client and Server mode.

This might need some squashing and rebasing before merging, as I've duplicate commits.

Also, for better maintainability, we should have a script that automatically update SSL certs, and put them in a folder, so that we don't have to update them when they expire.

[bjoernQ]

Good idea about the examples - maybe we should do something like we have in esp-wifi (while not everyone likes that approach) Also, I like the idea of having a script to update the certificates.

[AnthonyGrondin]

Considering how most of the code is identical between the architectures, I wonder if we could get by, by only using the arch as a feature for the different versions. We would have to specify the build target when compiling, but this doesn't seem to be a hassle per say.

[bjoernQ]

Considering how most of the code is identical between the architectures, I wonder if we could get by, by only using the arch as a feature for the different versions. We would have to specify the build target when compiling, but this doesn't seem to be a hassle per say.

That's what we initially did in esp-wifi and what we still do in esp-storage.

There is a lot of conditional compilation for initialization but that is not too bad. The real ugly thing there was the problem that we cannot have dev-dependencies (like esp-println etc.) per target (which are just features) which was fine for the Xtensas which each had their own "architecture" but for the RISCV chips they are all riscv32-imc and the later ones riscv32-imac.

I totally agree that having multiple identical copies of the same example code is also not idea