We had a few bugs that were causing things to get weird when a review request was discarded before its initial publish, and then attempted to use again. The first bug here is that doing an `rbt post -r` against the discarded review request would create the draft, but leave the review request in its discarded state. I've changed the POST /api/review_requests/<N>/draft/ API to reopen the review request in this case. Second, because there's some history present, the subsequent publishing of the discarded-then-updated review request is creating change descriptions. For the most part this is fine, but the commit list field wasn't correctly handling the case where the change was adding the first diff in the history. This affected both the serialization to the ChangeDescription as well as the rendering methods. Last, the draft banner was unconditionally trying to add an interdiff link. I've changed this to work like other parts of the codebase where we check the diff revision first. Testing Done: - Ran unit tests. - Manual testing: 1. Created a new review request draft, then discarded it. Saw that the old draft diff was discarded as expected. 2. Ran `rbt post -r` to update the previously discarded review request. Saw that it was reopened, and that the diff was correctly attached to the draft. Checked that the draft banner did not attempt to give us a bogus interdiff link. 3. Published the draft. Saw that publishing worked without showing errors, and that the change description was rendered correctly.