Add enums for keywords used in exit lists, Torperf measurement results, bridge pool assignments, and soon sanitized web logs

[karsten]

Todo derived from the discussion in comments 1 to 4:

Add keywords for all descriptors to Key enum.
Use a one letter prefix for keywords from non-Tor data sources.
First step: determine the best letter for each non-Tor source.

Original summary: We recently introduced the Key enum with keywords contained in relay descriptors, sanitized bridge descriptors, and sanitized bridge pool assignments. We did not include keywords in exit lists and Torperf measurement results, and in retrospect we should have excluded sanitized bridge pool assignments there.

The reason why each data source should have its own enum is that naming conventions might vary in terms of upper/lower case and word separators. For example, Tor descriptors use lower-case-keywords, exit lists contain CamelCase, and Torperf/OnionPerf use ALL_UPPER_CASE_WITH_UNDERSCORES. There could be conflicts for keywords like source vs. SOURCE.

[iwakeh]

Right, all descriptor parsing should make use of the Key keywords.

Some things to consider:
There is no inheritance between enums. So, the ease of use in all descriptor parsing code would be lost with different Key-enums. When using only the general Enum<T> the .keyword and other features of Key are lost.
This yields toward the "adding more Key enums approach" instead of separate Enums.

There are no naming conventions yet (only implicitly). The possible naming problems suppose certain rules which were not introduced directly.
A working set of naming convention rules could be started with the aim of only using one Key enum. If there are similar Key names as in the example above using 'source' a prefix could be added. It should be ok to not have a strict translation rule from the actual keyword to the enum name; only keep it heuristically close.

[karsten]

Ah, good point. How about we add a single-letter source prefix as in T_NETWORK_STATUS_VERSION("network-status-version") where T_ would stand for "Tor descriptor"?

[iwakeh]

Single letter is fine.
As most Tor keywords are defined already and I assume there are more Tor related ones than non-Tor, I'd prefix non-Tor descriptors. This would also accommodate non-Tor keywords from different data sources that overlap. This is a different prefix for each non-Tor source.

[karsten]

Works for me. In any case, prefixing Tor keywords can be done really easily, and it only affects the implementation, not the interface. If we ever decide to also prefix Tor keywords, we can just do it.

[iwakeh]

True! I added the new todos to the summary for easier reference.

[iwakeh]

Will be completed in 2018.