libnetservices.a: fix unit test builds after hrev54923

FileRequest: Make Stop() cancel the request as soon as possible

This commit implements a check for the flag raised by Stop() to cancel
a given request as soon as possible. Cancelled requests will return
B_INTERRUPTED regardless of whether the request has completed,
on par with how BHttpRequest is behaving at the moment.

Change-Id: Ia8a95b910cff158c710c5b2ed58b4675e705642e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3071
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

tests/net: Working integration tests for HTTP client

This patch is part 1 of 3 with the goal of having a working
integration test harness for BHttpRequest. In this patch the existing
test cases were expanded and fixed for HTTP. In followup patches the
test harness will be updated to support HTTPS and reverse proxies.

Before this patch the tests for BHttpRequest had hard dependencies on
the external services httpbin.org and portquiz.net. These tests
eventually stopped working because the owner of those services made
changes, causing the assertions in these tests to fail.

The goal of these patches is to make a test harness that allows for
the same kinds of end-to-end integration tests but without any
external dependencies.

The test suite now includes a Python script called testserver.py which
is a HTTP echo server of sorts. When it receives a request, it will
echo the request headers and request body back to the client as a
text/plain response body.

The TestServer class manages the lifecycle of this testserver.py
process. Each test case calls Start() on the server to start a new
instance, and then it is shut down when the destructor is called. On
each invocation a random port is assigned by the kernel in TestServer,
and that socket file descriptor is provided to the child testserver.py
script.

Authorization tests are supported, currently implementing Basic and
Digest auth. If the test server receives a request for a path
/auth/<auth-scheme>/<expected-username>/<expected-password>, then the
appropriate authorization scheme will be employed. For example, if
/auth/basic/foo/bar is used as the path, then the server will expect
the Authorization header to contain an appropriate Basic auth
payload.

The tests now perform a bit more validation than before, validating
the expected HTTP headers and response body is returned from the
server.

The following tests are not fixed yet or were removed:
* PortTest was removed entirely since I'm not sure of the point of this
test, and that functionality seems to be covered by the existing tests
anyway.
* HTTPS tests are not functional yet, but will be in a followup
patch. THis requires updating testserver.py to generate a
self-signed TLS cert if --use-tls is provided.
* ProxyTest was disabled before this patch, but can be enabled in a
followup patch by providing a reverse proxy in the test harness.

Change-Id: Ia201ef4583b7636c61e77072a03db936cb0092be
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2243
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

Move geolocation test to the shared kit tests.

* Fix the build.

Add BGeolocation experimental API.

A BGeolocation object can query an online service to get geolocation
and geotagging data:
* LocateSelf() tries to locate the machine it is running on, by using an
online database of wifi access points
* Locate() (not yet implemented) searches a BString and converts it to
lat/lon coordinates (reverse geotagging)
* Name() (not yet implemented) finds a suitable name for the given
coordinates (address, building name, or anything fitting).

The default service used is openbmap.org, which is freely available but
not very accurate. A request has been sent to Mozilla to use MLS
(Mozilla Location Services), which is a bit more accurate but needs an
API key. MLS is used for geolocation on FirefoxOS, for mobile phones
which don't have a GPS, and the data can be contributed by Firefox for
Android or the dedicated MozStumbler app.

Alternatively, Google Maps also provide the service, but wants
people to pay for it. Google Maps data is more accurate as all Android
devices contribute data to it.

All 3 services use the same JSON-based API: we send a list of reachable
Wifi APs (mac address and signal strength), and we get lattitude and
longitude information, and possibly extra data which will currently be
unused.

This can be used to implement HTML5 geolocation with reasonably accurate
results, but it can also be used in other places. For example
FirstBootPrompt could try to guess a list of most likely languages and
keyboard layouts from it (if wifi is working at install time, that is).

Use libstdc++, libsupc++ and libgcc from gcc_syslibs.

* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.

Add tests for data URIs.

Make HttpRequest tests use the test framework

* Use httpbin.org as a server, rather than a local machine.
* Also add an HTTPS version

Rename url directory to "service"

* All "services kit" tests will move there.

Move geolocation test to the shared kit tests.

* Fix the build.

Add BGeolocation experimental API.

A BGeolocation object can query an online service to get geolocation
and geotagging data:
* LocateSelf() tries to locate the machine it is running on, by using an
online database of wifi access points
* Locate() (not yet implemented) searches a BString and converts it to
lat/lon coordinates (reverse geotagging)
* Name() (not yet implemented) finds a suitable name for the given
coordinates (address, building name, or anything fitting).

The default service used is openbmap.org, which is freely available but
not very accurate. A request has been sent to Mozilla to use MLS
(Mozilla Location Services), which is a bit more accurate but needs an
API key. MLS is used for geolocation on FirefoxOS, for mobile phones
which don't have a GPS, and the data can be contributed by Firefox for
Android or the dedicated MozStumbler app.

Alternatively, Google Maps also provide the service, but wants
people to pay for it. Google Maps data is more accurate as all Android
devices contribute data to it.

All 3 services use the same JSON-based API: we send a list of reachable
Wifi APs (mac address and signal strength), and we get lattitude and
longitude information, and possibly extra data which will currently be
unused.

This can be used to implement HTML5 geolocation with reasonably accurate
results, but it can also be used in other places. For example
FirstBootPrompt could try to guess a list of most likely languages and
keyboard layouts from it (if wifi is working at install time, that is).

Use libstdc++, libsupc++ and libgcc from gcc_syslibs.

* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.

Add tests for data URIs.

Make HttpRequest tests use the test framework

* Use httpbin.org as a server, rather than a local machine.
* Also add an HTTPS version

Rename url directory to "service"

* All "services kit" tests will move there.