Consider removing "vote=0"

This issue would be part of solving #29710 (closed).

Time ago, we added "restrictions" on which relays to add to the bandwidth file. These restrictions are that the relay should have been successfully measured at least twice (in the last 5 days) and the measurements took place in different days (more than 24h distance).

Then we added back the relays to the bandwidth file, but with the KeyValues vote=0 unmeasured=1, so that the authorities ignore them.

If we remove the vote=0 unmeasured=1 KeyValues, and give a bandwidth values to those relays, the number of relays in sbws' bandwidth file would increase.

If I interpreted correctly the way torflow behaves, it add to the bandwidth file all the relays it knows about, even if they failed to be measured last time. It uses the value it reported (see https://sbws.readthedocs.io/en/latest/torflow_aggr.html#differences-between-torflow-aggregation-and-sbws-scaling-may-2020) in its previous bandwidth file.

If we would use the last consensus weight as the bandwidth value, we could have the problem that any bug in sbws would accumulate/amplify over time (see #33871 (closed))