CC3200 (TI's C library) doesn't like it

https://e2e.ti.com/support/development_tools/compiler/f/343/t/554883

PUBLISHED_FROM=d0e9fb7ebb7d189d1a76451d609f1f1861c7a837

PUBLISHED_FROM=8449d4df2a4caf7afc0f9b50f85bb01d79b8c4eb

PUBLISHED_FROM=edb1063d3fd64e3c732f16b8bf101c065cdacddd

Digital signature key usage is required for the key to be used for (EC)DHE.

PUBLISHED_FROM=b33366d484aff2c478b2f44b85dba33d04d3a808

Currently only OpenSSL API impl, but the plan is to add more.

PUBLISHED_FROM=c85b26fa2312047768bdcf3eca583e60862aba90

PUBLISHED_FROM=a6f3f33432ce43b6d4462de623ba61a53e7f18df

PUBLISHED_FROM=574362ea7d90a17cd49963a430559824cfcff802

PUBLISHED_FROM=2c23e4a4dfc7129da657c5935f06335fc022394a

PUBLISHED_FROM=8b5c6f70d5582402f327c4da7baee7cc15ee13aa

PUBLISHED_FROM=48c8d4326ea8a24edd8d1ca011be9e7643219084

PUBLISHED_FROM=f554cc63dfea12455fe5e428c6ce5f3152774f8e

PUBLISHED_FROM=ea039cdc30aec44db074871ff6b2d2582f98b5c9

PUBLISHED_FROM=39a1c2a271c5cd961670e11c830105c17ba0b2e4

PUBLISHED_FROM=5bf5a007929b3b6275121f3cf949526e881fb482

PUBLISHED_FROM=3ee9478275c4b9253b1dd4f98a69cecc89290bce

PUBLISHED_FROM=f03b963aaec02574e47c28ee8033551440b94f2d

PUBLISHED_FROM=80481f8dbcb93d04eee51ecc6366949420a61f2f

PUBLISHED_FROM=cfd7de45e4357a17719501b8ab004c2edbd3e87e

PUBLISHED_FROM=2b82f3793b3c6d0cf1266e4cc0e67930f43002c5

PUBLISHED_FROM=46496c2d5340a0bbe4fe1c6c9ff187bc65d2d35f

PUBLISHED_FROM=774764f9d316e111912dae1fcaf2933141c59a60

Causes issues on Windows - looks like "parallel" makefiles
do not handle spaces in directory names properly.

PUBLISHED_FROM=5d83e737e9f81041db21fd82c32146471eac1764

PUBLISHED_FROM=3a99921093957c2ba9c1a0938fa00b3a29784d81

And pre-create directories for SDK for both nRF51 and nRF52.

PUBLISHED_FROM=00caf156f48da92804c6af8efe323535fbc5497d

Now all warnings are disabled on SDK files, and enabled on our
application's files.

Fixed a couple of things in nRF52 which were unnoticed because all
warnings were disabled there from the beginning.

PUBLISHED_FROM=a33ab22d0ce85efea364b80478986b88f4b0a3a2

PUBLISHED_FROM=f8b4e8650d72c2ec5525e0510fbc8a80f8645a14

PUBLISHED_FROM=66db56192ae710e3f865fef47593b49e0ed4f133

Unfortunately it turns out Nordic's examples were able to build with GCC
just because they suppressed all warnings; I had to do the same here
because there are some macro redefinitions of arm-none-eabi-gcc and
lwip.

TODO: resolve that and do not suppress warnings.

PUBLISHED_FROM=e65c7b0f2451f85765d958d7f67eb9262f7bc929

Now it works in hardware.

PUBLISHED_FROM=f223bde2d2bebe97513ce073eb887552bc3d93af

PUBLISHED_FROM=cded8f36e2833e7c256ba6cbca0ebf1f6012dee7

PUBLISHED_FROM=79d3bc5ba7887e2126b64d2ea804c62606264ce2

PUBLISHED_FROM=c3d59657adff247f565bf0be59192e32d5d0bbf6

PUBLISHED_FROM=2a76ccddb62b63caeaca3785a07d7d0b94125eaf

PUBLISHED_FROM=3caea25dec11260561349fa096547bd62ecdb509

PUBLISHED_FROM=1bd3308933354e147c4e8aa375728a1ede6d8ab4

Long-lived UDP "connections" i.e. interactions that involve more
than one request and response are rare, most are transactional:
response is sent and the "connection" is closed. Or - should be.
But users (including ourselves) tend to forget about that part,
because UDP is connectionless and one does not think about
processing a UDP request as handling a connection that needs to be
closed. Thus, we begin with SEND_AND_CLOSE flag set, which should
be a reasonable default for most use cases, but it is possible to
turn it off the connection should be kept alive after processing.

PUBLISHED_FROM=1677d8024aa9afa7e18d8a04d829b699f7f2f103

PUBLISHED_FROM=57c62a4123a54ecb455dbf91f3fe562fb0cf2ec2

Also, do not require -DRTOS_SDK and pick socket/low-level event manager
based on LWIP_SOCKET.

PUBLISHED_FROM=d4afbdf8dab62a1c6ac4ca075c4a58887223dba4

PUBLISHED_FROM=c4f3d44ed16dba60db3198b90478c1b2e6f2a5c1

PUBLISHED_FROM=ec4c4ec1ca7fee10c67fbba5a603d59fe44a046d