fix: provide date for revisions in bibtex output

[maybe-hello-world]

Closes #5933

[codecov]

Codecov Report

Merging #6029 (8691896) into main (09f3477) will decrease coverage by 0.05%.
The diff coverage is 76.19%.

@@            Coverage Diff             @@
##             main    #6029      +/-   ##
==========================================
- Coverage   88.67%   88.63%   -0.05%     
==========================================
  Files         288      288              
  Lines       40001    40010       +9     
==========================================
- Hits        35471    35461      -10     
- Misses       4530     4549      +19     

Impacted Files	Coverage Δ
ietf/doc/views_stats.py	74.80% <ø> (ø)
ietf/group/urls.py	100.00% <ø> (ø)
ietf/group/views.py	90.61% <ø> (+0.08%)	⬆️
ietf/ietfauth/widgets.py	84.61% <ø> (ø)
ietf/submit/views.py	84.60% <ø> (ø)
ietf/doc/views_doc.py	91.37% <25.00%> (-0.26%)	⬇️
ietf/nomcom/views.py	92.90% <33.33%> (-0.22%)	⬇️
ietf/doc/utils.py	87.15% <100.00%> (+0.01%)	⬆️
ietf/doc/views_status_change.py	93.38% <100.00%> (ø)
ietf/nomcom/templatetags/nomcom_tags.py	70.83% <100.00%> (+3.64%)	⬆️
... and 2 more

... and 2 files with indirect coverage changes

[maybe-hello-world]

@rjsparks is it possible that some DocHistory objects can have an incorrect time field value?

Example:
DocHistory object for draft-carpenter-eligibility-expand/03/ has the time field value set as 2020-07-01 16:41:15, while revision 03 became available at 2020-07-01 16:41:16 (one minute later).

Given this difference, if you will search for DocHistory.latest_event(rev='03', type='new_revision') from the revision DocHistory itself, you will not find any events, because DocHistory will search for events <= 16:41:15.
Meanwhile, a search from Document.latest_event(rev='03', type='new_revision') will return the correct submission of revision 03 at 16:41:16.

Corresponding history events from the webpage:
2020-07-01 16:41:16 -0700 03 Brian Carpenter New version available: draft-carpenter-eligibility-expand-03.txt
2020-07-01 16:41:15 -0700 03 (System) New version accepted (logged-in submitter: Brian Carpenter)
2020-07-01 16:41:13 -0700 03 Brian Carpenter Uploaded new revision

This issue is reproducible when for a given draft, there's a System message that the new version is approved at a time X, and then "new version is available" at time X + 1 minute.

Another example:
https://datatracker.ietf.org/doc/draft-ietf-quic-transport - revision 03, revision 07, revision 12, revision 14, revision 16, etc.

[maybe-hello-world]

So, regarding this PR - I can search for new_revision events in the Document corresponding to DocHistory (without the time__lte parameter), in that case, we will always find the correct revision submission even for time mismatches.

I'm afraid that even if what I described is a bug (and not my misunderstanding) and we will fix it, time values for all previous DocHistory objects still would be the same.