rkt run: acquire lock on container directory

stage0 acquires an exclusive advisory lock on the container directory,
leaving the fd open when executing stage1/init with the fd value stored in
the environment variable RKT_LOCK_FD.

stage1's fakesdboot.so shim prevents closure of RKT_LOCK_FD in nspawn by
replacing the close with a O_CLOEXEC fcntl, retaining the lock handle until
nspawn exits.

This facilitates simple and reliable container discovery by external
processes via flock() attempts on container directories.  Consult the
flock(2) and flock(1) man pages for information on advisory file locks.

With this change some basic lifecycle features are trivial using bash:

 Identifying which containers are active:
  shopt -s nullglob
  for c in /var/lib/rkt/containers/*; do
   flock --exclusive --nonblock "$c" echo "$c inactive" || echo "$c active"
  done

 GC of inactive containers:
  shopt -s nullglob
  mkdir -p /var/lib/rkt/gc
  for c in /var/lib/rkt/containers/*; do
   [ -e "$c/stage1" ] || continue
   flock --exclusive --nonblock "$c" mv "$c" /var/lib/rkt/gc
  done

 Assuming a periodic task clears out aged contents from /var/lib/rkt/gc
stage1: record pid of container's init process in $cuuid/pid

Intercept syscall() used by systemd-nspawn for clone, writing the
newly-namespaced child's pid into /var/lib/rkt/containers/$cuuid from the
parent before returning to systemd-nspawn.

This change combined with locking enables simple status queries of running
containers, for example in bash:

 shopt -s nullglob
 for c in /var/lib/rkt/containers/*; do
  [ -e "$c/pid" ] || continue
  flock --exclusive --nonblock "$c" /bin/true || {
   echo $c
   cpid=$(cat "$c/pid")
   nsenter --mount --uts --ipc --pid --root --wd --target "${cpid}" systemctl status
  }
 done
Documentation: Fix image manifest in getting started guide

The "app manifest" is now called "image manifest" and its structure has
changed. Fix that up.

Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Merge pull request #262 from penberg/docs/getting-started

Documentation: Fix image manifest in getting started guide
Merge pull request #244 from vcaputo/lock_dir-record_pid

rkt run: acquire lock on container directory and record pid
path: update to new manifest path
Merge pull request #263 from jonboulle/manpath

path: update to new manifest path
cas: switch to bufio.Reader to eliminate a read

Using a bufio.Reader we can peak at the header of our input without
consuming the entire thing. Then we can decompress on the fly directly
from the input reader. This allows us to write it into a TeeReader that
both puts it into the store and generates a hash.

This eliminates one full read+decompress from the store.
Merge pull request #264 from jonboulle/cas

cas: switch to bufio.Reader to eliminate a read
General cleanup of README.

- Added CWD context to commands for clarity
- Added note about libseccomp dependency
- Re-worded some English for clarity
- Re-ordered Launching an ACI section for clarity

Signed-off-by: Daniel Farrell <dfarrell@redhat.com>
README: update for v0.1.1 of appc/spec
Merge pull request #272 from jonboulle/v011

README: cleanup and update to spec
tar: fixing extracting files that are dirs https://github.com/coreos/rocket/issues/250
tar: ensuring dir mode extraction
tar: fixing extracting files that are dirs #251

Merge pull request #251 from mcuadros:master
docs: update getting started guides
Merge pull request #274 from jonboulle/fixguide

docs: update getting started guides
Create parent directories for every file type and not for only regular files.
Merge pull request #275 from sgotti/tarcreateparenteveryfile

pkg/tar: create parent directories for every file type
cas: clean blockTransform, panic intentionally

There was a bug in diskv (https://github.com/peterbourgon/diskv/pull/20)
which meant that the blockTransform function could be passed an empty
string. In our case this just paniced after trying to split + access
parts of the resulting empty slice.

Panicking is arguably correct behaviour (if we ever get something that's
not a hash it's likely a bug in our code), but let's be more intentional
about it.