Order of sanitizing bridge descriptor tarballs matters even though it shouldn't
There's a bug in how metrics-db tries to repair references between bridge network statuses, server descriptors, and extra-info descriptors. In theory, the order of processed tarballs shouldn't matter, because we have a mapping file with hashed bridge fingerprint, descriptor publication time, server descriptor digest, and extra-info digest. But apparently this approach is buggy. I just tried sanitizing 1 week of tarballs in forward and in reverse order. The result was that sanitized descriptors differed. I suspect the problem is that bridges can publish more than 1 descriptor in a single second, but I'm not sure yet. I'm also not sure whether this leads to data loss or not. More analysis required. We might have to sanitize all bridge descriptors again.