Fix race condition in 030-trackingreview.py

The test creates a review that tracks a remote branch using the
/submitreview operation, and then immediately rebases it to track a
different remote branch using the /rebasereview operation.

Since /submitreview also schedules an immediate update of the tracked
branch (by the branch tracker background service,) we need to
synchronize to avoid the branch tracker's update happening at the
wrong time, conflicting with the review rebase.
Drop redundant "NOT NULL" constraint on primary key column

Primary keys have implicit not null constraints.  (Except in SQLite,
apparently, but we don't really care about that.  Constraints are not
supposed to be violated ever, so no huge issue that they are missing.)

The reason for this change is to make the SQL more uniform, which makes
automatic translation of non-standard features (like "SERIAL" here)
easier.
Read at most environ["CONTENT_LENGTH"] bytes of request body

This is actually required by PEP 333:

  The server is not required to read past the client's specified
  Content-Length, and is allowed to simulate an end-of-file condition
  if the application attempts to read past that point.  The application
  should not attempt to read more data than is specified by the
  CONTENT_LENGTH variable.

Since mod_wsgi simulates end-of-file, our old behavior worked just fine.
But wsgiref doesn't, and instead blocks until the browser closes the
connection (which naturally makes it hard to write a response back,) so
this more correct behavior is required for compatibility with wsgiref.
Make a random slightly dynamic SQL query somewhat simpler

SQLite doesn't support a boolean data type or the keywords "TRUE" or
"FALSE".  This we will have to work around either way, since there are
cases where we really want to use "TRUE" or "FALSE", but here we didn't
really need it.
Rename some columns whose names are SQL keywords

The columns reviewfilechanges.{from,to} might as well be named from_state
and to_state.  This means they don't need to be quoted in queries as much.
Restructure queries to avoid "complicated" RETURNING clause

RETURNING is a PostgreSQL:ism, and is hard to work around in the general
case (though quite simple to workaround in the "RETURNING <the id of the
single row we just inserted>".)  Here it wasn't exactly a must to use it.

Also simplify surrounding queries using repository/local_name to identify
a tracked branch to use the id of the tracked branch instead (the id
column is a late addition, relatively speaking.)
Use COUNT(table.column) instead of COUNT(table.*)

The latter is not supported by SQLite (might be a PostgreSQL:ism.)
Rewrite various queries to avoid non-standard DELETE/UPDATE syntax

The "DELETE FROM ... USING ..." and "UPDATE ... FROM ..." syntax
extensions for doing joins in DELETE and UPDATE statements is another
PostgreSQL:ism.  A rather convenient one, but quite easy to avoid in
most cases.

I've confirmed that PostgreSQL's query planner comes up with exactly the
same strategy in the two cases

  DELETE FROM x USING y WHERE x.a=y.a and y.b

and

  DELETE FROM x WHERE a IN (SELECT a FROM y WHERE b);

which should mean that there's no performance drawback to use the
seemingly more complicated sub-query variant.

In some cases the rewrite splits a query into two, one that selects
from 'y' and one that deletes from 'x' using cursor.executemany() and
the results from the first query.  This ought to be slightly slower,
since it's two queries instead of one and since the data is actually
transferred from the database server and back.  But in the cases where
such a split was necessary, there's not expected to be a huge amount
of data to transfer, and the performance impact is expected to be of
little significance.
Use SUBSTR(...) instead of SUBSTRING(...)

The former is supported by both PostgreSQL and SQLite, the latter only
by PostgreSQL.  The former also has less crazy call syntax.
Don't have list-of-1-tuples where list-of-ints was expected

The list was fed back as an argument to cursor.execute(), and apparently
the 1-tuple elements got translated into plain values by psycopg2 at some
point.  Not so by sqlite3, which rejected the parameters.
Return "403 Forbidden" for "/static-resource/"

This is what Apache does, and there's a TC that checks this.
Avoid using NULLS LAST when reading preferences

SQLite doesn't support it, and it's hard to work around in the SQLite
compatibility layer.  It's also quite unnecessary; we're selecting a
maximum of 3 rows, so fetching all and picking the right one client-side
works just as well.
Qualify ambiguous "id" column

Don't know why PostgreSQL didn't complain, or, for that matter, which of
the two candidate "id" columns it used to order the results.  (Not that
it typically would have mattered; both would usually give the same order.)
Don't call the changeset service in the middle of a transaction

SQLite doesn't support concurrent write-access to the database, so if
we do the changeset service will fail to write to the database, saying
that "the database is locked."
Support adding tracked branch with different local and remote name
Fix "git http-backend" integration's use of environ["wsgi.input"]

Notably, don't read the request body for methods that don't send one.
With wsgiref, the environ["wsgi.input"].read() call will hang forever.
And it obviously makes no sense trying anyway.
Set HEAD in new repository to be the mirrored branch

HEAD will be "master" by default, so if the mirrored branch isn't named
"master", HEAD will be a dangling reference (until a branch named "master"
is pushed manually) which causes "git clone" to fail to check out a work-
tree when cloning from the repository.

(Normally, the mirrored branch is of course named "master".)
Fix catch-all error handling when DB connection has been closed
Improve caching of static resources handled internally

Static resources (stylesheets and scripts) referenced from generated HTML
pages have a base-36 encoded timestamp in the query string, which means
they can essentially be cached forever.  This is implemented when Apache
handles the resources via mod_expires, so handle it here as well.

This handling is actually a bit more accurate, setting the generous cache
control headers only when the URL contains a (correct) timestamp.  This
means sub-resources (i.e. images referenced from stylesheets) are not
affected, since their URLs do not have the timestamp.  This is of course
a bit unfortunate; we want them to be cached as well.
Give highlight and changeset "max_workers" setting better default

Calculate based on number of CPUs on the system instead of hard-coding to
the value 4.  Also actually use this setting, instead of hard-coding to the
value 4 again.  (It was read as "max_jobs" instead of as "max_workers".)