Update japanese release note for 1.4.2
Merge pull request #708 from basho/feature/1.4.2-release-notes-ja

Update japanese release note for 1.4.2
Speed up manifest pruning

With many manifests (I'm testing 10k or so), this is _significantly_
faster than the from_list/to_list roundtrip.
Return updated manifests from Riak write

Previously we would write updated manifests to Riak, but would return
state ones from the function call. This could cause manifests that were
marked as `scheduled_delete` to get reverted back into the `active`, or
`pending_delete` state.
Fix bug in check for overwritten manifest versions that results in
deletion metadata being erroneously updated. This bug was masked by
the bug fixed by commit 87c6304ddbbeada7013f2cdb2e0974c2b18b2d4a.
Merge branch 'bugfix/manifest-pruning' into release/1.4
Change GC daemon to optionally use paginated 2I queries

Change the GC daemone to optionally use paginated 2I queries to avoid
system stress and timeouts when the amount of garbage to be collected
is large. The `paginated_indexes` boolean option is used to enable the
use of paginated queries and may be used when the version of Riak
being used is >= 1.4.0. The default for the option is false. There is
also an option, `gc_batch_size`, to configure the amount of results
that should be requested by the 2I query at one time. The default for
this option is 1000.
Improve handling of Riak disconnection errors on object downloads

Change the behavior when a Riak connection is closed during an object
downloading. There is existing retry logic to handle the case when
n_val=1 block requests fail with a notfound or timeout error. It is
desirable to also retry requests in the case of a transient connection
failure, especially in the case of the download of a sizable
object. Allowing the disconnect error to trigger the retry logic
provides time for the automatic reconnection process to work and
provides a mechanism for in-progress downloads to continue and
complete successfully.
Merge branch 'bugfix/retry-block-fetch-on-disconnect' into release/1.4
Remove emacs tmp file
s/paginated_indexes/gc_paginated_indexes/
Upgrade to lager 2.0.1

This allows us to use lager's tracing again without fear. The fix is in
basho/lager#175.
Merge pull request #730 from basho/bugfix/upgrade-lager-to-2.0.1

Upgrade to lager 2.0.1
Consider manifests for pruning based on count

If the `riak_cs` application env `max_scheduled_delete_manifests` is set
to an integer (default is `unlimited`), manifests will not only be
pruned based on `scheduled_delete_time`, but based on the number of
`scheduled_delete` manifests there are. If there are more than
`max_scheduled_delete_manifests`, they will be sorted by time (more
recent first), and then cut-off at `max_scheduled_delete_manifests`.
This means that in cases where a key is overwritten frequently, we have
the option of pruning manifests more frequently than just the leeway
time.
Add an EQC test for count-based manifest pruning
Don't register access archiver processes

The registered name is never used, so this allows more than one access
archiver process to be run.

Fixes #717
Merge branch 'feature/paginated-2i-for-gc' into release/1.4
Merge pull request #717 from basho/bugfix/allow-multiple-archiver-processes

Only a single access archiver can run at a time
Merge pull request #732 from basho/feature/prune-manifests-based-on-count

Consider manifests for pruning based on count
Don't delete current object version on bad md5

Fixes #705

Previously, writing an object with an incorrect md5 would not only cause
that write to be garbage-collected, but would remove any existing object
at the key. This fix does not pro-actively schedule the incorrect object
for garbage-collection. This is because
`riak_cs_gc:gc_specific_manifests/5` expects a Riak Object, and we don't
have one as a return-value of `maybe_update_manifest_with_confirmation`.
Returning something other than `ok` from that, and related functions
would be a bit of a refactoring, and would provide information that most
callers don't need. This can be an optimization down the road, as the
bad object will still be garbage-collected once it's been seen that it
was never moved from `pending_delete` to `scheduled_delete`.