mv api/unstable/*.h -> api/s2n/unstable/*.h

[graebm]

Issue:

External projects can always do:
#include <s2n.h>

But, for the unstable headers the path is either
#include <s2n/unstable/cleanup.h>
or
#include <unstable/cleanup.h>

...depending on whether s2n was installed before your project, or built at the same time as your project via CMake's add_subdirectory(s2n). CRT language bindings like aws-crt-python build s2n via add_subdirectory.

Description of changes:

• Move api/unstable/*.h -> api/s2n/unstable/*.h
  • This way, #include <s2n/unstable/XYZ.h> works regardless of how s2n was built
• Update all code to use new path

Call-outs:

I tried to use a symlink from api/unstable -> api/s2n/unstable, to keep the old paths working too, but it was confusing tools like cp -r and zip. See failed build here.

An alternate fix was attempted here: #4826
It relies entirely on one symlink and changes very few files, but it's failing for the same reason as the symlink mentioned above.

Testing:

• Ensured unstable headers still install to same location
• Ensured code still built when using old unstable/*.h paths
• Ensured code built when using new s2n/unstable/*.h paths

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jmayclin]

Approving since this shouldn't be a breaking change for anyone consuming s2n-tls from as an installed lib, but long term I think we need stronger language discouraging external consumption of s2n-tls from an add_subdirectory context.

add_subdirectory is not compatible with s2n-tls's reliance on configure-time feature probes for libcrypto capability detection.

[graebm]

Don't merge this yet. I'll see if I can stop the CRT libs from consuming S2N via add_subdirectory...

[graebm]

Yeah, closing this.
Didn't realize till I'd written the PR description, that what the CRT libs were doing with add_subdirectory() is downright shenanigans