Want to avoid reimplementing obsolete/deprecated stuff in Arti

While reviewing and tidying up the server-descriptor.md (!310 (merged), !312 (merged), ...) I have come across a number of no-longer-useful protocol elements that are still in the specs and which, apparently, are still generated and demanded by current implementations. That is, current implementations either generate or tolerate them, or maybe insist that they are there, and insist on some of the formatting requirements, but nothing should actually use the information.

Examples include RSA relay keys and TAP keys (proposal 350). There is also sometimes redundant information, such as the same public key encoded in different ways.

A surprisingly large proportion of entries in the server descriptor are obsolete in this sense. This means that we could save development effort if we could get rid of them from the network so that we don't need to reimplement them. (This is particularly true of consensus and server descriptor items for which we must otherwise implement entirely useless item-specific validation and consensus computations in arti dirauth.)

IMO we should aim to avoid reimplementing useless and obsolete things in Arti as much as possible. However, there are client distinguishability concerns. And, this has implications for our development schedule: it seems likely that the schedule would benefit from us not having to reimplement old stuff, if we can arrange a way to do that without lots and lots of churn work.

I think that given the lead times for protocol changes across the network we need to address this question as a priority. And, I think this is a project-wide issue.

CC @nickm in particular, and CC @dgoulet for the arti-relay ORport team, but the whole team may want to have an opinion.

List of obsolete things

• RSA relay keys
• TAP keys proposal 350
• In server descriptors:
  • eventdns
  • allow-single-hop-exits
  • master-key-ed25519
  • fingerprint
  • ntor-onion-key base64 =-padding
  • tunnelled-dir-server
  • or-address more than once
  • or-address entirely (needs router to accept IPv6)
• opt prefix on netdoc item lines (see !315 (merged))
• Dual hashing of RNG output in SRV calculation !323 (diffs, comment 3133973)
• In consensuses and votes:
  • Optionality of consensus-method[s]
  • client-versions and server-versions and associated machinery? See #303
  • package
  • Relay flags Valid, Running, NoEdConsensus, V2Dir