specialize Preparer a bit, so resourcePrepare can be added

The forall a. in Preparer made resourcePrepare not seem to be usable, so
I specialized a to Bool. Which works for both Preparer Storer and
Preparer Retriever, but wouldn't let the Preparer be used for hasKey
as it currently stands.
S3: support chunking

The assistant defaults to 1MiB chunk size for new S3 special remotes.
Which will work around a couple of bugs:
  http://git-annex.branchable.com/bugs/S3_memory_leaks/
  http://git-annex.branchable.com/bugs/S3_upload_not_using_multipart/
convert glacier to new ChunkedEncryptable API (but do not support chunking)

Chunking would complicate the assistant's code that checks when a pending
retrieval of a key from glacier is done. It would perhaps be nice to
support it to allow resuming, but not right now.

Converting to the new API still simplifies the code.
document that encryption + bup = inneficient
hook: use ChunkedEncryptable
Merge branch 'master' into newchunks
convert bup to new ChunkedEncryptable API (but do not support chunking)

bup already splits files and does rolling deltas, so there is no reason to
use chunking here.

The new API made it easier to add progress support for storeKey, so that's
done. Unfortunately, bup-split still outputs its own progress with -q,
so a little ugly, but not too bad.

Made dropping remove the branch for an object, for two reasons:

1. The new API calls removeKey to roll back a storeKey when the content
   changed unexpectedly.
2. So that testremote will be happy.

Also, fixed a bug that caused a crash when removing the branch for an
object in rollback.
convert ddar to new ChunkedEncryptable API (but do not support chunking)

Since ddar de-deuplicates, I assume there is no benefit from chunking.

This has not been tested!
better byteRetriever

Make the byteRetriever be passed the callback that consumes the bytestring.

This way, there's no worries about the lazy bytestring not all being read
when the resource that's creating it is closed.

Which in turn lets bup, ddar, and S3 each switch from using an unncessary
fileRetriver to a byteRetriever. So, more efficient on chunks and encrypted
files.

The only remaining fileRetrievers are hook and external, which really do
retrieve to files.
whitespace
Merge branch 'master' into newchunks
rsync: support chunking

Chunking does not speed up rsync at all, so it's only useful for
interop with the directory special remote.
roll ChunkedEncryptable into Special and improve interface

Allow disabling progress displays, for eg, rsync.
remove redundant progress meter display code

specialRemote handles all meter display, so this is redundant.
move ugly rsync zombie workaround

This reaping of any processes came to cause me problems when redoing the
rsync special remote -- a gpg process that was running gets waited on and
the place that then checks its return code fails.

I cannot reproduce any zombies when using the rsync special remote.
But I still can when using a normal git remote, accessed over ssh.
There is 1 zombie per file downloaded without this horrible hack enabled.

So, move the hack to only be used in that case.
finish making rsync support chunking

This breaks gcrypt, which relies on some internals of the rsync remote.
To fix next..
convert gcrypt to new regime, including chunking

Some reorg of Remote.Rsync code to export the things gcrypt needs.
Merge branch 'master' into newchunks
finally properly fixed ssh zombie leak

The leak was caused by the thread that sshd'd to send transferinfo
not waiting on its ssh. Doh.
when not using rsync (for local gcrypt repo), display own progress meter