add BoringSSL support

[LukasKastern]

This PR integrates boringssl.
I've been using a variation of these changes for a while now.
I would like to upstream these changes to avoid relying on my fork in other projects.

Compile as

zig build -Dtarget=x86_64-windows -Doptimize=ReleaseFast -Dlibpsl=false -Dlibssh2=false -Dlibidn2=false -Dnghttp2=false -Ddisable-ldap -Duse-boringssl=true

And run

./zig-out/bin/curl https://httpbin.org/uuid

Output

{
  "uuid": "1e7c8860-cdab-4e05-881a-763665242b79"
}

Ideally we wait until the following PRs are merged to avoid relying on my forks in the boringssl repository.

• Upgrade to 0.16.0 googletest#6
• Fix package failure occuring when patch step resides in sub-package akunaakwei/zig-patch#1

[Techatrix]

I just merged a PR that updated googletest to Zig 0.16.0 so this should be unblocked.

I'd prefer to keep the dependencies within the allyourcodebase organization if possible. Which would allow me and other members to more easily contribute if needed. Would you be open to join allyourcodebase and then contribute your boringssl port to it? More information on how to join can be found here:

https://github.com/allyourcodebase#im-a-zig-user-and-i-want-to-contribute-a-repository-how-can-i-do-it

[Techatrix]

Could you explain this change and why it's correct?

The old logic is taken from upstream:
https://github.com/curl/curl/blob/94962a9b82b5d6a13f5f75ae41e6cb3b58e25601/CMakeLists.txt#L1435

[LukasKastern]

I don't think I'd label it as correct. But I do think it's preferable. Without it we don't embed the host's ca bundles even though ca_bundle is set to auto.

I think this is a reasonable decision to make in CMake. Simply because cross compiling via CMake requires a lot of setup already. Therefore providing the CA bundle for your target environment, next to your toolchain file is not that far of a stretch.

But in zig, at least personally, I always cross-compile. The upstream behavior here breaks SSL when doing so. By default building a non working version of curl.

This was surprising to me when I integrated the library in another project.

Without this change I'd have to explicitly provide the ca bundles and pass them down the dependency chain. Which is fine. I'd just move the detection logic up the chain.

[LukasKastern]

I just merged a PR that updated googletest to Zig 0.16.0 so this should be unblocked.

I'd prefer to keep the dependencies within the allyourcodebase organization if possible. Which would allow me and other members to more easily contribute if needed. Would you be open to join allyourcodebase and then contribute your boringssl port to it? More information on how to join can be found here:

https://github.com/allyourcodebase#im-a-zig-user-and-i-want-to-contribute-a-repository-how-can-i-do-it

That makes sense! I'll update boringssl to use the merged googletest and ping kristoff about joining the org and moving the project over.