refs-be-db.c: add a database backend for the refs

Add a new type of refs backend that offloads the refs storage to a separate
refs daemon using a domain socket.
Communications with this new daemon goes through a socket and uses
7 simple rpc functions:

fetch, store, delete, traverse, start_transaction, cancel_transaction and
commit_transaction.

An example refs daemon will be released as a separate project. This
reference daemon will use a simple key-value store to store all the refs
and will serve as an example to use and modify for other databases.

The patch introduces a new file refs-be-db.c which implements a new
refs backend and the required methods. This file implements a simple schema to
store refs and reflogs in a key value store and then passes simple RPCs
across to the refs daemon for the actual integration with the database.

Two new configuration variables are added:
core.db-repo-name:
  Which is an arbitrary ascii string that names the repo.
  The repo-name is part of the refs daemon protocol thus allowing
  using one single database/database daemon to store the refs for
  many/all git repositories on the host.
core.db-socket:
  Path to the unix domain socket to use for communication with the daemon.

clone.c and init-db.c has two new arguments :
--db-repo-name=<>
--db-socket=<>
both of which must be specified if you want to use an external database
daemon instead of storing the refs as files under .git

Handle submodule support by requiring that a submodule, and any gitlink,
points to a repository that has compatible backend configuration.
For the database backend this means that the submodule/gitlink target
is also using the database backend and that it is using the same database
daemon.

Change-Id: I4611a39da112b1592db5797a5b7754727801100a
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
git-submodule.sh: create submodules using same backend as main repo

When creating a submodule create a submodule with the same type of
database backend as the amin repo. Automatically generate a repo name
based on the main repo name and the submodule name as :
<main-repo-name>_submodule_<submodule-name>

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
path.c: update validate_headref to handle db ref
 backends

Update validate_headref to take an extra path argument to specify
which directory to read the git data from. If NULL then as before
this means we try to use the cwd.

Change the two callers to pass the optional path as argument.

In validate_headref, try to read the db configuration from "config"
and if this is possible, check if core.db_repo_name is set or not.
If we can not read the "config" file, then fail.
This changes behaviour of this function and makes the "is this a valid
.git directory" check a little bit stronger since the previous code would only
check if the file "HEAD" exist.

IF core.db-repo-name is set then we treat this as sufficient proof that
the directory is valid and implicitely that HEAD exists in the database.

If core.db-repo-name does NOT exist we fall back to the original check
to try to open the "HEAD" file and check that it looks sane-ish.

Change-Id: Ic4d73edea262c207fde5e868782e9e0f67c84e89
Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
refsd-tdb: example refs database daemon

refsd-tdb.c is a simple reference implementation of a refs daemon.
This will eventually be hosted in a separate project but can live in this
branch for now.

Compile with :
gcc refsd-tdb.c -o refsd-tdb -l tdb

Run with:
./refsd-tdb /tmp/refsd.socket /tmp /tmp/refsd.log

Once the refs daemon is running you can start using it with newly
created git repositories by specifying the --db-socket and --db-repo-name
arguments to git clone/init-db :

git clone --db-repo-name=ROCKy --db-socket=/tmp/refsd.socket <some repo> .

This refs daemon is an example. It should be relatively straightforward
to modify it to attach to any other kind of data store.

Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>