Always add own fingerprint to effective family.

Some relays include their own fingerprint in the family line of their
server descriptor and others don't.  To provide consistent data Onionoo
now adds a relay's own fingerprint to its effective family.

Implements task-25241.

It is less effort to attempt the removal w/o knowing the set contains the string
to be removed.
Make use of the toArray method in Collection.

Some relays include their own fingerprint in the family line of their
server descriptor. If we don't remove a relay's own fingerprint, we'll
include it in the relay's effective family, because obviously the
relay agrees with itself about being in a family. Let's just remove
it, it's redundant information.

Fixes #25241.

We recently changed the 3 month bandwidth graph to 24 hours detail,
and we changed the compression of various status files to support 6
month graphs with 24 hours detail. However, we did not consider that
we currently need weights data for the last 3 months on a detail of 12
hours. This commit adapts the output file by using the data that we
now have. Maybe it even makes sense to use the same detail in both
graphs, though that was not the original intention.

Previously, we'd have compressed histories to a resolution of 48 hours
after 3 months. But we're now planning to introduce a 6 month graph
with a resolution of 24 hours. With this change we're retaining
detailed histories for three months longer.

Related to #24729.

Relays and bridges have recently changed their bandwidth statistics
reporting interval from 4 hours to 24 hours. As a result, our 3 month
bandwidth graph cannot accommodate new bandwidth statistics anymore.
Increasing the bandwidth graph interval to 24 hours changes this, by
reducing data resolution from 184 to 92 data points.

Fixes part of #24729.

Previously, we'd have used the last-seen time of the relay/bridge that
we're writing a document for. But that doesn't make much sense,
because we don't have to provide, e.g., a 1 week graph for a relay
that has been offline for years. This change is going to shrink the
out/ directory to a similar size as it was when we used current system
time for writing documents.

Avoid multiple definitions of date-time related constants.

When we consider a history interval from start to end, we really mean
the interval [start, end[. Fixing a few off-by-one bugs in the code.

In the spec we write: "Contained graph history objects may contain
null values if less than 20% of network statuses have been processed
for a given time period."

However, in the code we checked less than or equal. We should fix
that.

Related to not relying on system time for writing histories, we also
shouldn't rely on it for compressing histories anymore. Otherwise we
might be compressing the history of a relay or bridge that recently
went offline while expecting an uncompressed history of that relay for
writing history documents. In short, let's do the same when updating
*Status objects as we do when writing *Document objects.

Related to #16513, but not strictly part of it.

Rather than on system time we're now depending on the last time a
relay or bridge was seen in a consensus or status to determine when
history ends for this relay.

This has the advantage of making the write step deterministic, and it
produces the exact same graph intervals for the different documents of
a given relay or bridge.

A minor downside is that we're now depending on node statuses _and_
another status file in order to produce a history document. Should be
okay.

Define graph end as last full data point before the relay/bridge was
last seen.

Also make sure that graphs end at that defined graph end and do not
continue just because there's more history available. This is mostly
to exclude falsely-reported statistics.

Implements #16513.

Relays include the $ in fingerprints that they report in their family
line. We remove that $ when computing effective and extended families
and add it back later when writing details documents. With this change
we're taking out that last step.

Implements #22261.

Add a "recommended_version" parameter to return only relays and
bridges running a Tor software version that is recommended or not
recommended by the directory authorities.

Implements #23544.

Add a "recommended_version" field to bridge details documents based on
whether the directory authorities recommend the bridge's version.

Implements #21827.

Extend the "version" parameter to also return bridges with the given
version or version prefix.

Implements #23962.

Add a "version" field to relay details documents with the Tor software
version listed in the consensus and similarly to bridge details
documents with the Tor software version found in the server
descriptor.

Implements #22488.

We said we'd announce new major versions 1 month in advance. Today
we're going to put out a release to include this date for the first
time. Re-scheduling next major version for in 1 month from today.

Implements #21637.