Including modifications by Philip Withnall <withnall@endlessm.com>

C_IN macro was added years ago in bcbaf1bef0, using same value as the
internal code of Android with the reasonning that "some parts of the API
used by the resolver objects is not public in the Android NDK (yet)".
Well since then things are changed, since it is definitely available (at
least on the API 22 of Android which I am using) in the public header
arpa/nameser_compat.h.
Let's just add a #ifndef to handle both cases when you build with an
older or recent API.

Some very odd systems have the functions to initialise and destroy a
struct __res_state, but apparently not to do a DNS query using it. Fix
the compilation on those systems.

https://bugzilla.gnome.org/show_bug.cgi?id=794606

res_query() uses global state in the form of the struct __res_state
which contains the contents of resolv.conf (and other things). On Linux,
this state seems to be thread-local, so there is no problem. On OS X,
however, it is not, and hence multiple res_query() calls from parallel
threads will compete and return bogus results.

The fix for this is to use res_nquery(), introduced in BIND 8.2, which
takes an explicit state argument. This allows us to manually store the
state thread-locally. If res_nquery() isn’t available, we fall back to
res_query(). It should be available on OS X though. As a data point,
it’s available on Fedora 27.

There’s a slight complication in the fact that OS X requires the state
to be freed using res_ndestroy() rather than res_nclose(). Linux uses
res_nclose().

(See, for example, the NetBSD man page:
https://www.unix.com/man-page/netbsd/3/res_ninit/. The Linux one is
incomplete and not so useful:
http://man7.org/linux/man-pages/man3/resolver.3.html.)

The new code will call res_ninit() once per res_nquery() task. This is
not optimal, but no worse than before — since res_query() was being
called in a worker thread, on Linux, it would implicitly initialise the
thread-local struct __res_state when it was called. We’ve essentially
just made that explicit. In practical terms, this means a
stat("/etc/resolv.conf") call per res_nquery() task.

In future, we could improve this by using an explicit thread pool with
some manually-created worker threads, each of which initialises a struct
__res_state on spawning, and only updates it on receiving
the #GResolver::reload signal.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

https://bugzilla.gnome.org/show_bug.cgi?id=792050

Setting a variable and then assigning it to itself avoids
-Wunused-but-set-variable but this specific trick is now caught by
-Wself-assign. Instead, actually use the value or don't bother
assigning it at all:

gdbusauth.c: call g_data_input_stream_read_byte() in void context
gdbusauthmechanismsha1.c: value is actually used
gdbusmessage.c: use consistent preprocessor-token protection
gthreadedresolver.c: skip over bytes in data blob
httpd.c: do something useful with the value

https://bugzilla.gnome.org/show_bug.cgi?id=745723

Sub-directories inside gio/ already processed in a previous commit:
- fam/
- gdbus-2.0/ (which contains only codegen/)
- gvdb/
- inotify/
- tests/
- win32/
- xdgmime/

Other sub-directories inside gio/:
- completion/: no license headers
- kqueue/: not LGPL, BSD-style license

https://bugzilla.gnome.org/show_bug.cgi?id=776504

See https://developer.gnome.org/hig/stable/typography.html

https://bugzilla.gnome.org/show_bug.cgi?id=772221

This makes them easier to identify when debugging and profiling.

This patch was somewhat less than interesting to write.

https://bugzilla.gnome.org/show_bug.cgi?id=767765

https://bugzilla.gnome.org/show_bug.cgi?id=756477

I don't believe any real app would hit this, but we do leak
if it occurs.

Spotted by static analysis.

https://bugzilla.gnome.org/show_bug.cgi?id=733576