glib: Improve documentation for g_strfreev()

Fixes #740309.
GSettings: delay backend subscription

GSettings objects begin watching for changes as soon as they are created
in order that they can emit the "changed" signal.

In the case of dconf, if we want to be able to emit the changed signal,
we need to go on the bus and add some match rules.  This requires
creating the dconf helper thread and also requires initialising GDBus
(which creates another thread).

Some users of GSettings are never interested in the "changed" signal.
One of these users is the glib-networking code that gets run every time
a new network connection is created.

Some users are reporting that they are annoyed that simply establishing
a network connection would spawn two extra threads and create a D-Bus
connection.

In order to avoid doing unnecessary work for these simple uses, delay
the subscription until we know that we will actually need to do it.

We do this in a simple way, using a simple argument: in order for the
user to care that a value changed then they must have:

 1) watched for a change signal; and then
 2) actually read a value

If the user didn't actually read a value then they cannot possibly be
interested in if the value changed or not (since they never knew the old
value to begin with and therefore would be unable to observe that it
ever changed, since they have nothing to compare the new value with).

This really is a behaviour change, however, and it does impact at least
one user: the 'monitor' functionality of the GSettings commandline tool,
which is interested in reporting changes without ever having known the
original values.  We add a workaround to the commandline tool in order
to ensure that it continues to function properly.

It's also possible to argue that it is completely valid to have read a
value and _then_ established a change signal connection under the
(correct) assumption that it would not have been possible to miss a
change signal by virtue of not having returned to the mainloop.
Although this argument is true, this pattern is extremely non-idiomatic,
and the problem is easily avoided by doing things in the usual order.

We never really talked about change notification in the overview
documentation for GSettings, so it seems like now is a good time to add
some discussion, including the new rules for when one can expect change
signals to be emitted.

https://bugzilla.gnome.org/show_bug.cgi?id=733791
gsettingsschema: Print the string that failed to parse

When parsing a translated value fails, print the actual string that
failed to parse instead of the 'domain\004string' untranslated string.

https://bugzilla.gnome.org/show_bug.cgi?id=737150
https://bugzilla.gnome.org/show_bug.cgi?id=737160
GSettings Registry Backend: Init cache_lock Earlier

In commit 8ff5668, we are subscribing the GSettings backend later, but this
meant that we need to initialize cache_lock earlier, as we might try to
use that lock before a change notification is issued to subscribe the
backend, which would then cause an access violation if we are trying to
read GSettings values, as that lock is used to access the Windows Registry.

Initialize cache_lock once we initialize the GSettings Registry backend,
and delete it upon finalize, so that g_settings_read_from_backend() can
proceed normally, even if the GSettings backend is not yet subscribed.

https://bugzilla.gnome.org/show_bug.cgi?id=740413
GTlsClientConnection: loosen the semantics of "use-ssl3"

If SSL 3.0 has been disabled (at the host, application, or library
level), then the "use-ssl3" property becomes a "fail-immediately"
property.

Despite the name, the point of the property wasn't really specifically
to use SSL 3.0; it was to allow fallback when talking to broken
servers that do SSL/TLS negotiation incorrectly and break when they
see unexpectedly-high version numbers. So if we can't fall back to SSL
3.0, then the "use-ssl3" property should fall back to TLS 1.0 instead
(since there are hosts that will reject a TLS 1.2 handshake, but
accept a TLS 1.0 one).

glib-networking is being updated to implement that behavior, so update
the documentation here.

https://bugzilla.gnome.org/show_bug.cgi?id=738633
gio: Implement g_app_info_get_default_for_uri_scheme for windows.
gio: Implement g_win32_app_info_launch_uris for windows.
gparam: Make the documentation clearer for CONSTRUCT_ONLY properties

It's not that the properly will only be set on construction, it's that
it *can* only be set upon construction.
gio: Prevent hang when finalizing GThreadedSocketService

If all users of a GThreadedSocketService release their references to the
service while a connection thread is running, the thread function will
release the last reference to the service which causes the finalize to
deadlock waiting for all threads to finish (because it's called from the
thread function).

To fix this, don't wait for all threads to finish in the service's
finalize method.  Since the threads hold a reference to the service,
finalize should only be called when all threads are finished running (or
have unrefed the service and are about to finish).

https://bugzilla.gnome.org/show_bug.cgi?id=712570
gio/tests: add a socket-listener test

Add a GSocketListener test program. Currently the only test is a
regression test for bug 712570 (based on a standalone bug reproducer
provided by Ross Lagerwall).
2.43.1
gstrfuncs: Add g_strv_contains()

Includes unit tests.

https://bugzilla.gnome.org/show_bug.cgi?id=685880
Use the new g_strv_contains

No need to keep our own copy of this in the testsuite.
GSettings: fix check for delaying backend subscription

g_settings_has_signal_handlers() checks whether any of the signals has
pending handlers. However, g_signal_has_handler_pending() matches on
exact detail, even when passing 0. Subscribing to one of GSettings'
signals with a detail will fail this check and never connect to the
backend.

Fix this by calling has_handler_pending() with the key as detail as
well.

https://bugzilla.gnome.org/show_bug.cgi?id=740848
gsignal: add a clarification to the docs

As evidenced by a mistake that I made recently, this documentation could
use a little bit of clarification.
gmain: fix poll record comparison

We intend to keep the list of poll records sorted by (integer) file
descriptor, but due to a typo we are actually keeping it sorted by
pointer address of the GPollFD.

Fix that.

https://bugzilla.gnome.org/show_bug.cgi?id=11059
GVariant tests: test with larger strings

Allocate some larger strings in the testcase to make sure we handle them
correctly as well.
gnetworkaddress: Add g_network_address_new_loopback() constructor

This is a convenience method for creating a GNetworkAddress which is
guaranteed to return IPv4 and IPv6 loopback addresses. The program
cannot guarantee that 'localhost' will resolve to both types of
address, so programs which wish to connect to a local service over
either IPv4 or IPv6 must currently manually create an IPv4 and another
IPv6 socket, and detect which of the two are working. This new API
allows the existing GSocketConnectable machinery to be used to
automate that.

Based on a patch from Philip Withnall.

https://bugzilla.gnome.org/show_bug.cgi?id=732317
gsocket: add G_IO_ERROR_CONNECTION_CLOSED

Add G_IO_ERROR_CONNECTION_CLOSED as an alias for
G_IO_ERROR_BROKEN_PIPE, and also return it on ECONNRESET.

It doesn't really make sense to try to distinguish EPIPE and
ECONNRESET at the GLib level, since the exact choice of which error
gets returned in what conditions depends on the OS. Given that, we
ought to map the two errors to the same value, and since we're already
mapping EPIPE to G_IO_ERROR_BROKEN_PIPE, we need to map ECONNRESET to
that too. But the existing name doesn't really make sense for sockets,
so we add a new name.

https://bugzilla.gnome.org/show_bug.cgi?id=728928
Updated Vietnamese translation

Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>