Remove libcurl_vendor

[sloretz]

This is a step towards ros2/ros2#1150 - I want to remove libcurl_vendor so I don't have to figure out how to change where it installs headers. I think this has been discussed in #62

[sloretz]

CI (build: --packages-above-and-dependencies resource_retriever test: --packages-above resource_retriever)

• Linux
• Linux-aarch64
• Windows

[clalancette]

We tried this before, and failed: #64 . That said, if you can make it work I'd be happy to do this.

[sloretz]

Another windows attempt - will probably fail due to .dll.a/.a issue found in #64, but I want to see if the location of curl.exe can be used as a hint to find_package:

[sloretz]

Windows test again

[sloretz]

Again

[sloretz]

Another idea:

[sloretz]

Not out of ideas yet:

[sloretz]

Again

[sloretz]

Again

[sloretz]

Again

[sloretz]

Still going:

[sloretz]

Adding paths to help find_program and find_library find the chocolatey install:

[sloretz]

Using CMAKE_PREFIX_PATH

[sloretz]

Looking a little more promising

[sloretz]

Ok, I know how to make removing libcurl_vendor work, but I don't think it's worth it.

This PR finds the chocolatey version of curl and builds against it by finding the chocolatey curl.exe. To do that it has to ignore the curl.exe shipped in Windows 10 in C:/Windows/System32. That's no problem, except it will find a curl.exe in C:/ProgramData/chocolatey/bin/curl.exe .

That executable is a "shim" created with a chocolatey tool called shimgen. The point of shimgen is to allow executables to be run without the directory containing the .dll's they rely on being on PATH. To link against curl, we want to know what the directory with the .dlls is. This PR gets it by running the found chocolatey curl.exe with the argument --shimgen-noop. That causes it to output text that says where the real executable is. That output includes this line:

path to executable: C:\ProgramData\chocolatey\lib\curl\tools\curl-7.81.0-win64-mingw\bin\curl.exe

This PR parses that output and adds the path which contains bin/curl.exe (C:\ProgramData\chocolatey\lib\curl\tools\curl-7.81.0-win64-mingw\) to CMAKE_PREFIX_PATH. That allows the builtin FindCURL.cmake to find and build against the chocolatey version of curl. The problem is, that still doesn't add the .dll files to PATH at runtime.

It would be possible to make an environment hook that also finds chocolately curl and uses the --shimgen-noop output to get a path to add to PATH when call install/setup.bat is run, but that seems like a lot of work for not a lot of gain. Additionally, the chocolatey attitude seems to want to make these libraries unavailable. I'm surprised it installs the header files at all given how it hides the libraries. Maybe the header files won't be in the package in the future.

Compare that with the chocolatey package we ship for log4cxx where we explicitly add it's libraries to PATH. I don't think the curl package shipped in chocolatey is ever going to expose that, so let's not build against it.

# Add lib directory to path for dlls.
Install-ChocolateyPath "$env:ChocolateyPackageFolder\lib" -PathType "Machine