fetcher: Unref pending result when completing

Otherwise we were just leaking it.

https://bugzilla.gnome.org/show_bug.cgi?id=725921
Limit metadata to 10 MiB

If fetching GPG-signed commits over plain HTTP, a MitM attacker can
fill up the drive of targets by simply returning an enormous stream
for the commit object.

Related to this, an attacker can also cause OSTree to perform large
memory allocations by returning enormous GVariants in the metadata.

This helps close that attack by limiting all metadata objects to 10
MiB, so the initial fetch will be truncated.

But now the attack is only slightly more difficult as the attacker
will have to return a correctly formed commit object, then return a
large stream of < 10 MiB dirmeta/dirtree objects.

https://bugzilla.gnome.org/show_bug.cgi?id=725921
Move Makefile.dist-packaging under packaging/
deploy: Set the immutable bit on the deployment root

This prevents people from creating new directories there and expecting
them to be persisted.  The OSTree model has all local state to be in
/etc and /var.

This introduces a compile-time dependency on libe2fsprogs.

We're only doing this for the root directory at the moment.

https://bugzilla.gnome.org/show_bug.cgi?id=728006
Add --disable-fsync option to both commit and pull (non-local)

On some storage configurations, fsync() can be extremely expensive.
Developers and users with slow hard drives may want the ability to opt
for speed over safety.

Furthermore, many production servers have UPS and stable kernels, and
the risk of not fsync'ing in that scenario is fairly low.  These users
should also be able to opt out.
ostree-remount: Check for / being *mounted* read-only, not necessarily writable

The previous S_IMMUTABLE commit broke ostree-remount; / is now not
actually writable.  All we really wanted to know though was whether it
was *mounted* writable, so check that via statvfs() which is cleaner
anyways (i.e. not via access() which kernel people hate).

https://bugzilla.gnome.org/show_bug.cgi?id=728006
Honor disable_fsync during checkout also

Finally, fsync to ensure all entries are on disk, unless disabled.
 We support disabling this for cases like server-side buildroot
 construction where we don't need to be robust against power loss
repo: Support fsync=false configuration

See rationale in the updated docs.  Basically developer use cases as
well as UPS-backed servers.
libostree: Make OstreeLibarchiveInputStream explicitly private

We weren't installing the headers, but at the moment all symbols
starting with ostree_ were being exported.  Fix that by prefixing
non-static symbols with '_'.

https://bugzilla.gnome.org/show_bug.cgi?id=731369
libostree: Make OstreeTlsCertInteraction explicitly private

Similar to previous commit, this should be private.

https://bugzilla.gnome.org/show_bug.cgi?id=731369
libostree: Make OstreeFetcher explicitly private

Per previous commit.  We're not attempting to export an HTTP to
clients, the high level API is ostree_repo_pull().

https://bugzilla.gnome.org/show_bug.cgi?id=731369
libostree: Silently ignore EPERM when setting EXT2_IMMUTABLE_FL

In the case of running ostree as non-root on a regular filesystem (not
tmpfs which doesn't support immutable), we should just silently do
nothing if we encounter EPERM.  Cache the result to avoid spam in
strace.

https://bugzilla.gnome.org/show_bug.cgi?id=728006
Release 2014.5
log: Print a friendly error if we haven't downloaded the complete history

For the local repository on the system, it's not the usual case to
have the complete compose history.  Rather than erroring out, provide
a bit more friendly message.

https://bugzilla.gnome.org/show_bug.cgi?id=731538
pull: Support --mirror option

There's several use cases for calling into ostree itself to do
mirroring, instead of using bare rsync.  For example, it's a bit more
efficient as it doesn't require syncing the objects/ directory.

https://bugzilla.gnome.org/show_bug.cgi?id=728351
cat: Fix a typo in usage error printout
commit: Hide --disable-fsync option, add --fsync which takes a boolean

Per discussion on mailing list, the --disable-fsync has a
double-negative thing going on; --fsync=false is clearer.
core: Fix g_file_get_uri/get_parse_name for non-root ostree files
tests: Add a test which exercises --fsync=false
pull: Emit a better error if the remote isn't found

The generic GKeyFile error isn't quite informative enough here.

I hit this with the new compose process where we don't automatically
inject a configured remote into the generated disk images; we expect
people to add them.

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