Consider adding a layer to permit renaming of signals

[krivard]

Via #239:

As we add sources and signals, our naming sometimes needs to evolve to remain clear and accurate. Right now we are stuck indefinitely with naming decisions we made long ago. We need a more flexible way to evolve while remaining backward compatible. We need to have a process for gradually deprecating old names.

This work would likely involve:

• a name-mapping table
• an additional step in assembling query parameters to map from the user-provided name to the appropriate signal key id

If there are sneaky design decisions in the details, we may want to put together a PRD for this to explore them -- the immediate questions that occur to me are:

• how is the name-mapping table updated? who is allowed to update it? how risky are updates to this table?

• New layer in API to support signal preprocessing and renaming #239 mentions adding deprecation notices for some renames:

  Enable naming evolution by using this layer to support backward compatibility, with some feedback about deprecation. So, the current API calls would still work, but would be translated into the new calls, and old signal names will be mapped into new signal names, for as long as we want, after which they will return a "please switch to the new name" error message.

  how should these be encoded? if a deprecation notice collides with another status message, how should we combine messages?

• does this need to be incorporated into pre-pandemic endpoints, or just those that use the v4 data model?

[melange396]

this sounds very related to an existing source/signal alias map:

delphi-epidata/src/server/endpoints/covidcast_utils/model.py

Line 260 in 6cdfdd4

def create_source_signal_alias_mapper(source_signals: List[SourceSignalSet]) -> Tuple[List[SourceSignalSet], Optional[Callable[[str, str], str]]]:

[dshemetov]

A related request. We have a pretty nice metadata retrieval and signal autocomplete functionality in epidatr (where you can do something like epidata$signals$ hit tab and get a list of source:signal pairs in your IDE and then get metadata/query them), but it's held back by the source/signal naming scheme containing hyphens - my auto-complete puts the signal name in with hyphens and then I have to manually surround it with backticks to get R to interpret the name as a string.

All that is to say: it would be nice to have aliases for all names where underscores replace hyphens.