So our jobsub_q_scraper agent *thinks* it's collecting a "hold reason" from the condor_q listing; but it somehow doesn't end up in the reason_held field on the job, and then isn't shown on the
Secondarily, when we parse the joblog there is a hold reason
028 (1023308.000.000) 11/09 23:15:12 Job ad information event triggered.
HoldReason = "Error from firstname.lastname@example.org: Docker job has gone over memory limit of 4096 Mb"
we should snag that, too.
* identify where naming problem occurs between jobsub_q -> bulk_update_job
* add HoldReason parsing to joblog parser
* make sure triage page lists reason_held