Bump OpenSSL 1.1.1 -> 3.6.3

[jhanca-robotecai]

Bump OpenSSL to 3.6.3 across all platforms

Unifies the O3DE OpenSSL 3rdParty package to 3.6.3, replacing the 1.1.1.

Changes

• Linux, Linux-aarch64, and Mac/Mac-arm64: source builds now target openssl-3.6.3.
• vcpkg path (Mac-Intel/iOS/Windows/Android): bumped the vcpkg pin to a commit shipping OpenSSL 3.6.3 natively; dropped the two legacy 1.1.1-era patches (set_openssl_port_to_1_1_1_x.patch, enable-stdio-on-iOS.patch); updated package metadata (OpenSSL changed to Apache-2.0).
• fixed two stale prerequisite checks in testing script: the qemu package no longer exists on modern Ubuntu, and the aarch64 binfmt check now also recognizes kernel-level binfmt_misc registration

Testing

• Linux x86_64: built and tested end-to-end via the real Docker pipeline
• vcpkg path: validated via a local Linux-triplet dry run of the new vcpkg pin
• Linux-aarch64, Mac/Windows/Android/iOS: left to CI

[nick-l-o3de]

Looks fine by me! Note that last I checked, it was used by Python, and Qt and a few other libraries, notably

• AWSGameLift stuff - and other AWS stuff - we don't maintain this anymore, so its not relevant. We should, in fact, consider eliminating any related folders. They'll be there in history, but we can close it up for now.
• Qt - note how the Qt build config.json refers to OpenSSL-1.1.1t-rev1-linux and windows. We may have to rebuild Qt to ensure they're all on the same platform here.
• Python - Python has crypto built into it because it is everything AND the kitchen sink. We may have to ship a new python, and thus a new Qt For Python (pyside6) lib too.
• O3DE uses it as far as I know in the networking platform.

[jhanca-robotecai]

Thank you for review and the comment about the usage.
The PR was marked as a draft, because I wanted to get some comments in #376 and fix tests.

Now most of the tests are fixed. The only one left is Android build - the compiler fails to build a package due to the build parameters, that are incorrect:

--target=armv7-none-linux-androideabi30 -march=armv7-a -mthumb

32-bit ARMv7 does not support 128-bit integer. The parameters are set based on CMAKE_ANDROID_ARCH, which uses defaults instead of the parameters passed from the outside.

[jhanca-robotecai]

The Android build is fully fixed.

[nickschuetz]

On the "we may have to rebuild Qt" point, I went digging through the Qt package scripts and I think it's only Windows that actually needs it.

Windows really does link it: build-windows.bat sets OPENSSL_ROOT to the OpenSSL-1.1.1o-rev1-windows folder (lines 29 to 35) and passes -openssl-linked to configure (line 55). So that one gets OpenSSL baked in and will need a rebuild once this lands.

Linux looks vestigial though. build-linux.sh takes the openssl package name as arg 3 and assigns it to OPENSSL_FOLDER_NAME on line 19, and then never uses it again anywhere in the script. The configure line is just -prefix / -submodules / -platform linux-clang / -nomake examples / -nomake tests / -release / -c++std c++20 / -opensource / -xcb / -confirm-license / -no-icu, with no OpenSSL flag at all. So the package gets downloaded and handed to the script and then ignored. The two Mac scripts don't mention openssl anywhere either.

That matches what I see in the binaries downstream: the Qt6 we ship in the Fedora packages has no TLS backend plugin at all (libQt6Network has all the QTlsBackend machinery and the "Current TLS plugin does not support..." strings, but no backend .so ever gets built or installed), and the engine itself has zero QSsl* references. Usual caveat that we rebuild Qt ourselves so our configure could differ from the official binary, but the script evidence above is straight from this repo.

So unless Windows is the blocker, I don't think Linux or Mac need a Qt rebuild for this. Might also be worth dropping the now-unused OpenSSL-...-linux and -linux-aarch64 entries from Qt's build_config.json at some point, though that's clearly separate from this PR.

Nice work on this by the way, getting off 1.1.1 is a big one.

[jhanca-robotecai]

Linux looks vestigial though. build-linux.sh takes the openssl package name as arg 3 and assigns it to OPENSSL_FOLDER_NAME on line 19, and then never uses it again anywhere in the script. The configure line is just -prefix / -submodules / -platform linux-clang / -nomake examples / -nomake tests / -release / -c++std c++20 / -opensource / -xcb / -confirm-license / -no-icu, with no OpenSSL flag at all. So the package gets downloaded and handed to the script and then ignored. The two Mac scripts don't mention openssl anywhere either.

The Linux script has a dead code related to TIFF_FOLDER_NAME and ZLIB_FOLDER_NAME as well. All three can be removed. I confirmed by pulling qt-6.10.2-rev8-linux: plugins/tls/libqopensslbackend.so has no static OpenSSL symbols at all (checked with ldd and nm).

Unfortunately we statically embed OpenSSL and export unhidden in _ssl.cpython-310-x86_64-linux-gnu.so and _hashlib.cpython-310-x86_64-linux-gnu.so, the same as in AzNetworking - which was a trigger for me to start investigate this topic due to the segfaults I encounter when linking my Gem to OpenSSL 3.x. Which means some more work to be done. But it should follow in the separate PRs.