API server code health pass - misc. refactors

[rzats]

Partially addresses #998.

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

Fixes a set of issues in the server code as described here.

• Splits _handle_lag_issues_as_of() into three separate methods, removes no-op usage.
• Reworks set_order() method to remove unneeded sorting complexity, renames to set_sort_order.
• Removes unused get_related_signals() method.
• Removes _db.py, moves the SQLAlchemy engine definition from it to _common.py.
• Expands usage of the IntValues type alias.

[melange396]

if we are gonna push the IntRange thing through, we might as well include it in other similar type variations... so like replace Union[str, Tuple[int, int], int] with Union[str, IntRange] too.

[melange396]

Suggested change

	self.order = [f"{self.alias}.{k} ASC" for k in args]
	self.order = [f"{self.alias}.{k} ASC" for k in args]
	return self

[rzats]

This is actually one of the refactors I wanted to apply to query.py - the return self is intended to be used for method cascading:

q.apply_issues_filter().apply_lag_filter().apply_as_of_filter()

but it is not used that way anywhere in the codebase, so the statements serve no purpose. Do we still need to keep the return self for some other reason? (Or perhaps start using that style of cascading after all?)

[melange396]

we can allow method cascading without requiring it. the rest of the methods of QueryBuilder do return self, and its best to keep that consistent especially in case someone does eventually choose to write something with cascading. its also not bad form to return self on mutator methods from a functional programming perspective.

[rzats]

Got it! I actually wanted to remove return self from those other methods too but you make a great point about the functional programming angle.