Turns out for long-running upgrades we were running them all in
parallel, which thrashes the disk pretty hard. This adds a simple mutex
lock around each upgrade, so at least the computer is usable while it's
going on. A more robust solution would be to have a single-thread
thread pool where we enqueue upgrades, but that's too much change this
late in the release cycle.
Also it turns out that the nullifying of the internaldate_time_t column
before we repopulate it was very costly, and unnecessary. So, this also
should speed things up for upgrading users.
Closes: bgo #724475
We had a bug in our DateTime to time_t conversion logic where all
time_ts would end up in the year 3800. This fixes that, and repopulates
the internaldate_time_t column with the new, correct time_t values.
Closes: bgo #724335
