[RFC] multi_ack protocol v2

Hi,

the fetch-pack/upload-pack protocol as of now goes like this:

- server sends the refs it has, then an empty packet
- client sends what it wants, then an empty packet
- client sends a rev-list via "have" lines in the hope to find a common
  rev. Interspersed, it sends empty packets.
- server answers to those empty packets with a NAK message, until it
  receives a "have" line for a commit it has (and which is therefore a
  common commit). This is answered by an ACK message, and no NAK or ACK is 
  sent after that
- client sends "done"
- server only responds if no common commit was found, with a NAK
- server sends pack

after thinking about my earlier approach, I think there's a better, less intrusive, and all in all just simpler approach:

- client asks for multi_ack protocol by sending " multi_ack" at the end
  of at least one "want" line
- server appends " continue" to the ACK message, but continues sending
  ACK (but not NAK) messages
- after receiving "done", server repeats last ACK message without 
  " continue" appended

After much fun with non-working, fragile code which had to be retracted from master, I hope that this approach is less prone to errors.

Note that this is incompatible to the multi_ack protocol I described earlier, but given that my patches were buggy anyway, I'd say it does not matter at all.

Thoughts, comments, objections?

Ciao, Dscho