Fossil SCM

The goals of this branch are:

• Reduce memory cost of outbound payloads which have a login card by eliminating one of the copies of the payload.

• Keep downstream clients (read as "libfossil") from having to perform the same memory-hungry juggling to generate their sync payloads.

It achieves those by enabling the sync layer's login card to be stored in the HTTP headers instead of in the sync body payload. Specifically, it writes the login card to a transient Cookie header (as distinct from a Set-Cookie header) which compatible remotes will recognize.

The sync workflow typically runs like this:

• Send a message to the server stating our intent, e.g. a push. At this point the client does not know whether the server supports this feature, so it must use the "legacy" login card format. The initial message is typically quite small, so this isn't usually a huge memory cost.

• When the server responds, the client inspects the traffic to see if the remote it supports the new-style login cards. If so, it makes a note of that so that subsequent posts for this same sync will send login cards as a cookie. (The server side of a sync never sends login cards - only the client side does.)

• Make any number of subsequent round-trips. At this point we know whether to use the cookie or not. Using it costs fossil less memory by eliminating an extra copy of the request body which otherwise needed to place the login card properly.

Many sync messages are quite small but posting of new files, or large changes, can cost considerable amounts of RAM (e.g. sqlite3.c requires something like 3MB to pack into the sync protocol), and those large packets now cost slightly less than half as much RAM to generate.

Design note: this change initially aimed to use a custom HTTP header, but that was incompatible with CGI-hosted fossils, which do not have access to the raw HTTP headers. Switching to a cookie was suggested in the forum and it turned out to be much simpler to implement that way.