Handle undefined `props` in manifests

Prior to Riak CS 1.3.0 (667319391c4ef3d5c0d757e11952a5202cc64050 in
particularly), manifests were written with `undefined` in their `props`
field, despite the record definition setting it to `[]`. This change
fixes the manifests as they are read, and 'upgraded'. That way, the rest
of the code-base can assume the field is a proper proplist.
Merge pull request #671 from basho/bugfix/handle-undefined-manifest-props

Handle undefined `props` in manifests
Create vsn.git at priv/ under top level directory
Add default proxy get cluster id

Can be set with:
`application:set_env(riak_cs, default_proxy_cluster_id, RemoteClusterID).`
Merge pull request #678 from basho/bugfix/toplevel-git-vsn

Create vsn.git at priv/ under top level directory
Fix build of riak-cs-ee so RIAK_CS_EE_DEPS envvar gets passed properly

During build of debian packages, the environment is cleaned by debuild
by setting all environmental variables to "".  This fact made the
passing of RIAK_CS_EE_DEPS variable work on accident until the `[]->false`
pattern was added to the rebar.config.script.  Though adding that
pattern fixed the OSS build, it did break debian package builds.

This commit fixes this by removing that check, but also not
automatically exporting the RIAK_CS_EE_DEPS makefile since an export
will export an empty variable and the rebar.config.script can now
trigger on an empty setting again.

Calling `unset RIAK_CS_EE_DEPS` is the only way to build an OSS
build after previously exporting the variable for riak-cs-ee.

In addtion a flag is passed into the debian's debuild so when
it RIAK_CS_EE_DEPS is available even when the environment is cleaned.
Merge pull request #687 from basho/bugfix/jem-debian-missing-repl-cs-ee

Fix riak-cs-ee build on debian
Merge pull request #686 from basho/feature/add-default-cluster-id

Add default proxy get cluster id
Append random number to epoch binary

Every CS DELETE execute GET/PUT to a single BKey = {riak-cs-gc, Epoch}.
Appending random number to Epoch (hopefully) solve this hot key problem.

GC daemon can collect garbage with suffixed key because it accesses
keys by binary range 2i.
Make logging in bucket listing map function lager version agnostic

The parse transform for lager changed between lager 1.2.X and lager
2.0.0. This causes problems listing the contents of buckets when using
Riak CS 1.4 or later with older versions of Riak because the
map_keys_and_manifests function is run on Riak nodes as part of a
MapReduce job. That function contains a lager call that is rewritten
to use a lager module that did not exist in versions prior to 2.0.0
and when run on Riak nodes that still uses an earlier lager version it
can result in errors. The errors happen when the bucket that a list
operation is run against contains a deleted object. This commit
changes the lager call in the map_keys_and_manifests function to use a
call that is not transformed and is safe for older Riak versions as
well as the 1.4.X releases.
Merge branch 'bugfix/map-keys-log-incompatibility' into release/1.4
Add option to allow a delay for the initial GC collection

Add an option that allows the initial run of the GC daemon to be delay
by some number of seconds. This provides a convenient way for the GC
daemon to be run on multiple nodes without overlapping the collection
and cleanup effort among nodes. The option is called initial_gc_delay
and is specified in seconds. The value only applies to the initial
collection run when the riak_cs node is started.
Merge branch 'feature/initial-gc-delay' into release/1.4
Throw away in-line if expression
Make GC key suffix max value configurable by application env

The default value is 256. In terms of scalability, larger value is better.
On the other hand, when there are more keys in GC bucket, listing keys takes
longer. The default value 256 is conservative, safe side.

If GC mechanism will be improved (streaming/multi-threading), we may safely
adopt larger value, for example 1024 or more.
Refactor: some specs and more congruent return types
Don't treat success as error for access stats

Webmachine 01f444cb75cbbe38420fcf08185c849ce5f169d7 introduced the
possibility of the response code being a two-tuple of HTTP code and a
custom 'reason'. Riak CS was not updated to support this, and so in
order to see if a response code was in the 500 HTTP range, we'd
accidently be comparing `{200, undefined} >= 500`, which incidentally,
returns true. This fix handles both integer HTTP codes and the new,
two-tuple format.

The bug manifested itself by having all operations in the access usage
statistics show up with the 'SystemError' prefix'.

Fixes #690
Merge pull request #697 from basho/bugfix/all-access-stats-in-system-error

Don't treat success as error for access stats
Merge pull request #689 from basho/feature/gc-key-scattering

Append random number to epoch binary
Set pb_backlog in Riak config for riak_test runs

Specify a pb_backlog of 256 in the Riak app.config for riak_test runs
to avoid spurious riak_test failures due to disconnected Riak pids.