The `gitno` buffer interface is another layer on top of socket reads.
Abstract it a bit into a "static string" that has `git_str` like
semantics but without heap allocation which moves the actual reading
logic into the socket / stream code, and allows for easier future usage
of a static / stack-allocated `git_str`-like interface.

The existing mechanism for providing options to remote fetch/push calls,
and subsequently to transports, is unsatisfactory.  It requires an
options structure to avoid breaking the API and callback signatures.

1. Introduce `git_remote_connect_options` to satisfy those needs.

2. Add a new remote connection API, `git_remote_connect_ext` that will
   take this new options structure.  Existing `git_remote_connect` calls
   will proxy to that.  `git_remote_fetch` and `git_remote_push` will
   proxy their fetch/push options to that as well.

3. Define the interaction between `git_remote_connect` and fetch/push.
   Connect _may_ be called before fetch/push, but _need not_ be.  The
   semantics of which options would be used for these operations was
   not specified if you specify options for both connect _and_ fetch.
   Now these are defined that the fetch or push options will be used
   _if_ they were specified.  Otherwise, the connect options will be
   used if they were specified.  Otherwise, the library's defaults will
   be used.

4. Update the transports to understand `git_remote_connect_options`.
   This is a breaking change to the systems API.

Next to including several files, our "common.h" header also declares
various macros which are then used throughout the project. As such, we
have to make sure to always include this file first in all
implementation files. Otherwise, we might encounter problems or even
silent behavioural differences due to macros or defines not being
defined as they should be. So in fact, our header and implementation
files should make sure to always include "common.h" first.

This commit does so by establishing a common include pattern. Header
files inside of "src" will now always include "common.h" as its first
other file, separated by a newline from all the other includes to make
it stand out as special. There are two cases for the implementation
files. If they do have a matching header file, they will always include
this one first, leading to "common.h" being transitively included as
first file. If they do not have a matching header file, they instead
include "common.h" as first file themselves.

This fixes the outlined problems and will become our standard practice
for header and source files inside of the "src/" from now on.

Some of our header files are not included at all by any of their
implementing counter-parts. Including them inside of these files leads
to some compile errors mostly due to unknown types because of missing
includes. But there's also one case where a declared function does not
match the implementation's prototype.

Fix all these errors by fixing up the prototype and adding missing
includes. This is preparatory work for fixing up missing includes in the
implementation files.

Function was added in commit 2c982daa on October 5, 2011,
and removed in commit 41fb1ca0 on October 29, 2012.
Given the length of time it's gone unused, it's safe to remove now.

This is another option which we should not be keeping in the remote, but
is specific to each particular operation.

Having the setting be different from calling its actions was not a great
idea and made for the sake of the wrong convenience.

Instead of that, accept either fetch options, push options or the
callbacks when dealing with the remote. The fetch options are currently
only the callbacks, but more options will be moved from setters and
getters on the remote to the options.

This does mean passing the same struct along the different functions but
the typical use-case will only call git_remote_fetch() or
git_remote_push() and so won't notice much difference.

The text progress and update_tips callbacks are already part of the
struct, which was meant to unify the callback setup, but the download
one was left out.

git_indexer_stats and friends -> git_transfer_progress*

Also made git_transfer_progress members more sanely
named.

Also removing all the *stats parameters from external
APIs that don't need them anymore.

This allows us to add capabilitites to both at the same time, keeps
them in sync and removes a lot of code.

gitno_buffer now uses a callback to fill its buffer, allowing us to
use the same interface for git and http (which uses callbacks).

If it's not available, an error saying so will be returned when trying
to use a https:// URL.

This also unifies a lot of the network code to use git_transport in
many places instead of an socket descriptor.

Trying to send every single line immediately won't give us any speed
improvement and duplicates the code we need for other transports. Make
the git transport use the same buffer functions as HTTP.

This changes the git_remote_download() API, but the existing one is
silly, so you don't get to complain.

The new API allows to know how much data has been downloaded, how many
objects we expect in total and how many we've processed.

Signed-off-by: schu <schu-github@schulog.org>

Taken mostly from the git transport's version, this can be used by any
transport that takes its pack data from the network.

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

1. The license header is technically not valid if it doesn't have a
copyright signature.

2. The COPYING file has been updated with the different licenses used in
the project.

3. The full GPLv2 header in each file annoys me.

There are many ways how a transport might negotiate with the server,
so instead of making it fit into the smart protocol model, let the
transport do its thing. For now, the git protocol limits itself to
send only 160 "have" lines so we don't flood the server.

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>

Move the generation of the want-list to be done from the negotiate
function, and keep the filtered references inside the remote
structure.

Signed-off-by: Carlos Martín Nieto <carlos@cmartin.tk>