There are two more bugs I ran into when creating attachments for a

FileDiff:


When creating a FileAttachment for a given FileDiff, we were creating

   a draft for the review request. Diff-specific attachments aren't part

   of the usual draft flow for the review request, so this isn't

   necessary.


Review requests and review request drafts both have relations to file

   attachments. When we create a new attachment for a FileDiff, we were

   correctly associating it with the review request, but we were not

   associating it with the draft. This meant that if there was a draft

   (as there often is when posting a new diff), publishing that draft

   would erase the relation to the ReviewRequest.


These objects also have a RelationCounterField for the FileAttachment

   relation, which is used when computing things like the ETag to

   shortcut if there are no attachments. This change also makes sure

   we're saving those fields when adding new attachments.

Ran unit tests.
Posted changes including binary files and no longer saw extra drafts.
Verified that the file_attachment_counts field was set correctly.
Published a diff and saw that my file attachments didn't disappear and

  file_attachment_counts didn't zero out.