[RFC] Restructuring and cleanup of mbedTLS configurations

[pfalcon]

Having submitted #6131, I see that there're more issues, so opening a more generic ticket to collect them and consider ways to address.

1. Zephyr's mbedTLS configs live in ext/lib/crypto/mbedtls/configs/ , which is not the right location, because these are Zephyr's configs, not 3rd-party content (many configs start from 3rd-party/upstream samples, but they are usually modifies and are Zephyr's own config). This is an old issue, which was already raised IIRC.
2. We don't have enough consistency among the configs, but should strive for that. For example, most systems Zephyr targets would have much larger ROM than RAM, and RAM being a scarce resource (especially with TLS usage) at all. So, MBEDTLS_AES_ROM_TABLES should be enabled by default. Currently, only 3 of 5 configs define it (but one of them twice). To achieve manageable consistency for this, we apparently need to introduce multi-level configs, e.g. introduce config-zephyr-common.h which other "leaf" configs would include.

[pfalcon]

We currently don't have multithreading support enabled in mbedTLS (MBEDTLS_THREADING_C config option). That's apparently based in the fact that all mbedTLS structures are per network context, as described in #6086 (comment) , but ... we have multi-threaded IP stack, so someone would need to explicitly sign off that we don't have any access concurrency. For example, entropy source is by definition system-wide, what happens if it's accessed from 2 different threads at the same time?

And if ideas in #6086 are implemented, we'd have more sharing, and definitely will need to synchronize concurrent accesses. At the same time, enabling MBEDTLS_THREADING_C will enable global access sync, which may be quite expensive and better be avoided.

https://tls.mbed.org/kb/development/thread-safety-and-multi-threading

[pfalcon]

Another issue is that we have quite an adhoc mbedTLS config file set as the default. #6221 addresses that.