pack.create_delta: fix copy operations that are larger than 2^24 bytes

This correctly decomposes copies of sequences longer than 2^24 into
smaller copy operations, so that really big blobs in a repository
don't result in corrupt packs.

Note that difflib.SequenceMatcher is worst-case O(n^2) on its input,
so this is very slow. We may want to add an optional parameter to the
packing code that specifies a maximum size to deltify (beyond that
size we'd just include fulltexts in the packfile.)

This will be tested by a follow-up change after we enable
deltification in our pack-building code, as the easiest way to prove
this works correctly involves building a pack and feeding it to
git-verify-pack.

Change-Id: Ic30fa433a2f3b88ddb1aacfe4788dbd47b2e4490
Add tests for encode functions.
pack.write_pack_data: when writing OFS_DELTA entries, write correct offset

The old code wrote the OFS_DELTA offset as the offset from the start
of the pack file, which is
wrong. git.git/Documentation/technical/pack-format.txt states that the
offset is the number of bytes before the current object header that
the base object header starts, which is what we now write.

A future patch will exercise this code by enabling the writing of
deltas during packing.

Change-Id: Ie8431339e4ca3a6cc4e1969b90150b7a6e464d4c
compat/test_pack: extract parsing of git-verify-pack output

A future test will want to reuse this same logic.

Change-Id: Icd36632331a514479cf8a89cdb0932a9eaf57e08
pack.write_pack_objects: when packing, actually build deltas

This results in producing smaller packs. Includes a test that verifies
the resulting pack contains a delta and passes git-verify-pack's
checks.

Change-Id: I63f875cfe412ad727bc1364e3ed0a2b1d7214260
For the moment, keep deltification disabled - but add a flag to enable it.
compat/test_pack: add test that proves we correctly handle medium-sized objects

What I mean by "medium" in this case is that they're big enough to
require three bytes worth of length information in a copy operation,
but not big enough to require decomposing a copy operation into
multiple sequential copy operations.

Change-Id: I82c28bf8bae5c5c9ed06b79f7380bcdcf4c501e3
Update NEWS.
compat/test_pack: add test that proves large copies in a delta encode correctly

Change-Id: I1a6104344cd960c62273539546cf1581510707f3
Disable test_delta_large_object for the moment, since it is slow.
Cherry-pick addition of --listen_address/--port argument from dulwich.server from a3be3876043e6bf14617a5584287de1e099dcabf.
Openstack Swift backend support for bare repositories

This patch adds a new SwiftRepo object that inherits of
BaseRepo. The SwiftRepo object knows how to deal with
git repositories stored on an Openstack object storage
Swift.

Regular filesystems are the defacto backend for Git
repositories but suffers of some limitations in term of
availability and scalability. Using Swift as backend, Git
objects are duplicated in multiple replica, that improves a lot
the disponibity of your repositories, avoids the downtime
due to infrastructure maintenance and also avoids the need to
configure backups. Extending a regular filesystem where
your repositories are stored can be risky and can leads to
downtime. With Swift as backend, extending the storage size
is transparent.

For more details have a look to the README.swift file
provided by this patch.
Move the swift backend to dulwich/contrib.

Subcommands for initializing repositories on swift are now available
from the dulwich.contrib.swift module. In the future, we could
expose this functionality as a dulwich-swift script. The main reason
I haven't done this yet is to keep it clear that this script is in
contrib.
Fix logic for extra adds of identical files.

Additionally, add a test.
Update NEWS.