CURL support for Bazel

[jsuereth]

This wires CURL into the BAZEL build, and enables the CURL http tests to also be run in the BAZEL build.

Fixes #390

Note: This does NOT provide CURL build in a consumable way for release, that will be done as part of a larger PR for enabling OT CPP releases to be consumed by downstream bazel users.

[codecov]

Codecov Report

Merging #402 (bebc4f5) into master (347ca02) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #402   +/-   ##
=======================================
  Coverage   94.74%   94.74%           
=======================================
  Files         175      175           
  Lines        7590     7591    +1     
=======================================
+ Hits         7191     7192    +1     
  Misses        399      399           

Impacted Files	Coverage Δ
ext/test/http/curl_http_test.cc	93.54% <100.00%> (+0.04%)	⬆️

[jsuereth]

@lalitb I got the build to work in bazel. It looks like there's some kind of runtime error in the CURL test for "POST" for windows/osx. I'm getting a non-zero exit code running the tests after I build locally. I'm going to take a deeper look when I can, but if you have any insight, it'd be appreciated.

[lalitb]

@lalitb I got the build to work in bazel. It looks like there's some kind of runtime error in the CURL test for "POST" for windows/osx. I'm getting a non-zero exit code running the tests after I build locally. I'm going to take a deeper look when I can, but if you have any insight, it'd be appreciated.

@jsuereth - I would instead suggest to remove the curl build/test for Windows, as we would like to have WinInet as the default http client for Windows. Either me/Max would work on this client. I will look into the osx failure, as it should work fine there.

[jsuereth]

Disabling the unit test on windows is out-of-scope for this PR (I'm still working on that entire mechanism, trying to make sure we don't go down a path of madness).

@lalitb I did get the CURL test working on windows CI, just not locally. I'll disable it in the future. For the Darwin build, it may be a similar issue to windows where the CURL -D definitions (in bazel) are NOT saved in a config.h for later usage, so you need to define a subset of them to compile against it.

[lalitb]

Disabling the unit test on windows is out-of-scope for this PR (I'm still working on that entire mechanism, trying to make sure we don't go down a path of madness).

@lalitb I did get the CURL test working on windows CI, just not locally. I'll disable it in the future. For the Darwin build, it may be a similar issue to windows where the CURL -D definitions (in bazel) are NOT saved in a config.h for later usage, so you need to define a subset of them to compile against it.

Have fixed the MacOS test now - it was something to do with how loopback address subnet is configured in MacOS.

[lalitb]

Add comment on why this fixes the timeout test?

Sorry for not being clear enough in my earlier comment. The fix is to change the non-existent IP address value from "127.0.0.X" to some random address "222.222.X.X". The reason was that loopback address subnet range is different in Linux and MacOS and so timeout test works in one, and fails in another. The new IP address won't be reachable in both the platforms, and so test will pass. Also reduced the timeout value to 2sec, to ensure that test won't take long time,

[ThomsonTan]

LGTM once the format issue is fixed.

[lalitb]

LGTM