Fix up remaining issues with parsing vote entries

While reviewing metrics-sql-tables!45 (merged) I was taking a closer look at all the digest parts and at the end at our vote parsing.

Take this entry for Najdorf in dannenberg's vote from 2024-10-15 18:00:00:

r Najdorf +vCogp45BjZp+mCbkE4PuNXh8j8 pkBE/G15w98wTUTqeEjoKWuLblI 2024-10-15 06:26:10 49.12.57.133 9001 0
a [2a01:4f8:fff0:4f:266:37ff:fee5:cc35]:9001
s Fast Guard HSDir Running Stable V2Dir Valid
v Tor 0.4.9.0-alpha-dev
pr Conflux=1 Cons=1-2 Desc=1-2 DirCache=2 FlowCtrl=1-2 HSDir=2 HSIntro=4-5 HSRend=1-2 Link=1-5 LinkAuth=1,3 Microdesc=1-2 Padding=2 Relay=1-4
w Bandwidth=10000
p reject 1-65535
id ed25519 zak6whupYxRKeYPtIfYJBlQrksWKIVeUYXuyc+WZBM4
stats wfu=0.984989 tk=1557063 mtbf=959199
m 28,29 sha256=EunLA7rIUXJVLeaxJ20DP6225AV/eO3S39YxPFtLSEI
m 30,31,32,33 sha256=8bumhgm3pxsWVlGWASCUyBjShx1ipfxPZbwZXHXM3A0

Looking at the output from all 9 directory authorities I think there are some fields wrong or misleading:

+------------------------------------------+------------------------------------------+------------------------------------------+------------------------------------------+
| nickname                                 | digest                                   | bandwidth_weight                         | supported_consensus_methods              |
+------------------------------------------+------------------------------------------+------------------------------------------+------------------------------------------+
| bastet                                   | bR7SzT2QeKySoKdzC5zGrXcWs80bj4CXbBaf3W3F+Q0 | 10000                                    | 30,31,32,33                              |
| tor26                                    | 44KmLV9W7JQQVP6CQ1V+ZzCU6hx0LoN2A/JMXjQdvyg | 10000                                    | 30,31,32,33                              |
| maatuska                                 | 3xosII/snYFk5TQDxoL7YdbBnOKFPkj0zSHWqt8D+So | 10000                                    | 30,31,32,33                              |
| moria1                                   | xkGPbrPJHKrgSoOjqWiUBKJZ8jSe5ilflfoTpLBRrDw | 10000                                    | 30,31,32,33                              |
| dannenberg                               | YtxKLa1BeexZ+gJmO0OWqSurPEz2GcI1UBT+8JYxxcM | 10000                                    | 30,31,32,33                              |
| longclaw                                 | A2qSPdzlRyCFOanRC5lsvQVlpPrNtLIV5bNH9JdTtRQ | 10000                                    | 30,31,32,33                              |
| dizum                                    | Ur9hq3x6MUn6m4uUx7c8EG3yd1NTTEZ07VbBGLYG32Q | 10000                                    | 30,31,32,33                              |
| gabelmoo                                 | CVMJ7ZaASsFidW0khJbMAO0Cx9K2/VIQCczu1Ec0kdw | 10000                                    | 30,31,32,33                              |
| faravahar                                | W4Z5/Ffj8ymecbHcd4CMBmAemFa/YCBxtXDTKE6L+Og | 10000                                    | 30,31,32,33                              |
+------------------------------------------+------------------------------------------+------------------------------------------+------------------------------------------+

First, digest in the r line is not the one over the whole document but the one from the server descriptor used (see: metrics-sql-tables!45 (comment 3094660)).

Then it's not clear what bandwidth_weight is doing. 6 out of 9 directory authorities include measurements, so the weight of the relay is at the end calculated using those results. The "placeholder" of 10000 is not used as we have enough bandwidth authorities to ignore the unmeasured values.

Finally, as one can see in the above vote entry there are two m lines, but it's shown only one without any hash values. So, we need to add all of that (missing m line values, hashes, and digest used).