Leonlu2/inequality issue time value

[LeonLu2]

closes #1085

Prerequisites:

• Unless it is a documentation hotfix it should be merged against the dev branch
• Branch is up-to-date with the branch to be merged with, i.e. dev
• Build is successful
• Code is cleaned up and formatted

Summary

1. add inequality operators handler for time_values and issues in server
2. add inequality tests in test_covidcast.py accordingly
3. other minor changes

[krivard]

Buncha questions to get through first

[krivard]

nit: using a length-1 tuple here feels weird

later on we're using the tuple type information to engage the inequalities logic instead of the range logic, so it's clearly needed, but it feels unsatisfying regardless

[krivard]

hey @rzats do you have any ideas for how we can more clearly indicate that a date parameter value is an inequality? the return value from this function is read in the date span processing at _query.py:45, dates.py:125, and dates.py:147, where inequalities need to be handled differently from other kinds of spans.

[rzats]

Yep, I can see what this PR is going for and there might be a better way to handle the inequalities. Right now this is returning a single-element tuple to fit within the following type structure;

IntRange: TypeAlias = Union[Tuple[int, int], int]
TimeValues: TypeAlias = Sequence[IntRange]

A clean solution would be to add a new type alias called IntStrRange which is a union of Tuple[int, int], int and a third type - either str if we just want to know what the inequality operator is or Tuple[str, int] if we want the date too.

TimeValues can then be replaced with a Sequence[IntStrRange], and we can then refactor the date span processing functions where TimeValues was previously used.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication

[krivard]

👍

Could merge as is but I'd like to hear Rostyslav's thoughts