Store PatchLineComments in Git notes

Teach ChangeNotes how to read the PatchLineComments out of a Git Note
object in the format specified below. Also, teach ChangeUpdate how to
write those notes to the correct ref. Note that this does not deal
with draft PatchLineComments at all.

Below is an example of what one of the notes would look like (there can
be up to one note per commit to which comments refer). This includes
not only the patch sets themselves but also their bases.
--------------------------------------------
Patch-set: 3
Rev-Id: abcd1234abcd1234abcd1234abcd1234abcd1234
File: path/to/file

5:1-40:10
Mon Jun 15 2014 03:03 PM
Author: Yacob Yonas <1@gerrit>
Parent: 000060
UUID: 000070
Bytes: 15
I do
not get it

35:1-40:10
Mon Jun 15 2014 04:04 PM
Author: Dave Borowitz <2@gerrit>
Parent: 000080
UUID: 000090
Bytes: 15
I do
not get it

File: path/to/other

70:1-70:100
Mon Jun 8 2014 12:01 PM
Author: Dave Borowitz <2@gerrit>
UUID: 000020
Bytes: 3
Why

-------------------------------------------
The first line of every note will either read "Patch-set: X" or
"Base-of-patch-set: X" to tell us whether the comments in this commit
refer to the base of a patch set or a patch set, as well as which
patch set. Then, we have the Rev-Id for the commit on which these
commits were made.  There is a block for all of the comments on each
file. This will either be the commit for the patch set or for its base
(we will know which one because of the first line of the note).  These
blocks will start with a line of the format: "File: path/to/file".
There is one block for each of the comments. Within a file block, the
comments on that file are sorted by comment range and then by
timestamp for breaking ties. If a comment doesn't have a range, we use
the line number field of the comment instead for comparison.

The first line of a comment block either contains the comment's line
number or its comment range. A range would be in the format
"1:1-100:2" while a line number would simply be one number on that
line. The comment range is optional in a comment, so we allow
either. If that line contains just a line number, the range field on
the PatchLineComment into which we are parsing will be left empty. The
second line of the comment block holds the timestamp for the
comment. Next we have information about the account that made the
comment. Then, we have the parent UUID and current comment UUID. Even
though the field, UUID, no longer lives in the reviewdb, we must keep
that field because of specifications for the REST API. It is important
to note that the line for the parent UUID will be omitted completely
if a comment does not have a parent (see third comment block for an
example of that). Then, the final field is the length of the comment
itself (not including the metadata) in bytes. Finally, after the
comment's actual message, there are two new line characters.

Change-Id: I07db8a252de9901e64e5a6936fa4df0cb3e0d338

gerrit-server/src/main/java/com/google/gerrit/server/git/VersionedMetaData.java

@@ -222,13 +222,20 @@ public abstract class VersionedMetaData {
           return;
         }
 
-        final ObjectId res = newTree.writeTree(inserter);
-        if (res.equals(srcTree) && !update.allowEmpty()) {
+        ObjectId res = newTree.writeTree(inserter);
+        if (res.equals(srcTree) && !update.allowEmpty()
+            && (commit.getTreeId() == null)) {
           // If there are no changes to the content, don't create the commit.
           return;
         }
 
-        commit.setTreeId(res);
+        if (commit.getTreeId() == null) {
+          commit.setTreeId(res);
+        } else {
+          // In this case, the caller populated the tree without using DirCache.
+          res = commit.getTreeId();
+        }
+
         if (src != null) {
           commit.addParentId(src);
         }