Unique identifiers for ChangeMessages and PatchLineComments were
generated using a seed from a database sequence, mixed together with
IdGenerator. In the spirit of killing ReviewDb, use a
cryptographically secure pseudorandom number generator to generate
these IDs instead. Follow the same "xxxxxxxx_xxxxxxxx" format so IDs
look similar.
I suppose the goal of the sequence-based approach was to decrease the
chance of collision by including a piece of state in each ID that is
guaranteed unique across the server. However, the chance of collision
for any 8-byte identifier can never be less than 1/2^64 no matter what
implementation we choose.
By definition a cryptographically secure PRNG generates random data
that is evenly distributed across the entire byte space, so the PRNG
implementation also has a 1/2^64 chance of collisions; we're just
swapping one rare-collision implementation with another. (This assumes
no bugs or weaknesses in the PRNG implementation, but with all due
respect to Shawn, I don't think the JDK's PRNG is any more likely to
have collision-introducing flaws than our hand-written IdGenerator.)
This change actually has no effect on ChangeMessage IDs that are
stored in or read from NoteDb, because ChangeNotesParser always
populates the ChangeMessage UUID field with the SHA-1 in the notes
graph of the commit that introduced the message; ReviewDb UUIDs are
simply discarded. The messageUuid method is still called during
creation because of the implementation details of ChangeMessagesUtil,
but that ID is not used for storage.
This change does have an effect on the IDs generated for
PatchLineComments, which also use messageUuid for their IDs, despite
the somewhat confusing fact that the ReviewDb interface implies the ID
is just for ChangeMessages.
While we're in there, rename the method to messageUuid to match the
Google Java Style Guide for camelCase names.
Change-Id: I7d157b9e8f87b41d4e7a146b705012863c27d42e
5a142312e9