more robust parsing of user counts

[jtracey]

The current userstats-relay-country.csv has the row 2024-08-21,de,2e+05,160074,263639,74, which causes this line to choke on the 2e+05. Arguably this should be fixed upstream (presumably there's a script generating this somewhere that never encountered a large round number of users before), but since we're never going to see anonymized usage metrics that lose anything from floating point precision, this fix is fine too.

[stevenengler]

This is kind of funny, I wonder what is writing the number like that.

The CI should be fixed as of #114. Could you rebase this PR onto the latest main?

[sporksmith]

The CI grabs this file from tor's metric server:

wget https://metrics.torproject.org/userstats-relay-country.csv

Later lines for the same locale are integers as expected, so yeah maybe we got unlucky on that particular data point to be exactly 200,000.

2024-08-20,de,200762,160365,261801,75
..
2024-08-21,de,2e+05,158805,264242,74
...
2024-08-22,de,200832,173292,246242,67

[sporksmith]

Filed https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40121 for the upstream issue