Consider adding a new interface RelayNetworkStatusMicrodescConsensus

[karsten]

There are currently three different version 3 network status document types, identified by the following @type annotations:

1. @type network-status-vote-3 1.0: these are votes exchanged by directory authorities;
2. @type network-status-consensus-3 1.0: these are (unflavored) consensuses based on votes and published by directory authorities;
3. @type network-status-microdesc-consensus-3 1.0: these are the same consensuses as before but using a specific flavor, in this case one that references microdescriptors rather than server descriptors.

So, while we're using a separate interface for the first type (RelayNetworkStatusVote), we're using the same interface (RelayNetworkStatusConsensus) for the second and third type. This only works, because the only differences between unflavored and microdesc-flavored consensuses can be found in the network status entries, and we're using the generic NetworkStatusEntry for those. But as soon as there will be new keywords in either unflavored or microdesc-flavored consensuses, we'll have to add support for them to RelayNetworkStatusConsensus, even though the other flavor doesn't support them.

We might consider adding another interface RelayNetworkStatusMicrodescConsensus for microdesc-flavored consensus, which would probably just extend RelayNetworkStatusConsensus for now (or copy over everything from it? uhhh). But if microdesc-flavored consensuses ever derive from unflavored consensus in header or footer, we'll be able to model those changes correctly.

Related to this suggestion, we might consider making NetworkStatusEntry less generic by using a separate Entry interface like we just did for ExitList. Following that model, RelayNetworkStatusVote.Entry would keep its getMicrodescriptorDigests() method, RelayNetworkStatusConsensus.Entry would drop that method, and RelayNetworkStatusMicrodescConsensus.Entry would get a getMicrodescriptorDigest() (singular) method.

I don't think these changes are super urgent, but I wanted to write them down before resolving #17000 where they first came up.

[iwakeh]

This should be considered when working on #19640.

[iwakeh]

Taking this on together with #19640.

[karsten]

We decided today not to let this ticket (and #19640) delay the 1.9.0 release, and 2.0.0 won't be a good target milestone either. Taking this out of planned milestones for now.

[iwakeh]

Be aware of #24028 when starting to work on this task.

[iwakeh]

Move to metrics-team as these are not worked on by me during the next week.