Refactoring thoughts

[DrMurx]

This is a meta-issue on all the "little" issues I found worth refactoring in the current code base which are too big to be done along the way.

Anti-patterns or unexpected code style

Certain patterns in the code make it harder to understand, and prevent or impede the creation of proper tests. Try to be as DRY (Don't Repeat Yourself) as possible.

• Consistent coding standard (PEP-8), also for HTML, JS and SQL.
• Use ORM or at least a DBAL with an SQL builder.
• CLI argument parser shouldn't be injected into classes or directly imported as singleton. Instead, inject only the required configuration options into the constructor.
• utils/resolution.py: The callers use this not as class but as some kind of "mixin" pattern.
• Communicator: Create high-level methods for certain tasks (eg. start RGC).
• if ... elif ... elif ... else instead of looping over a dict (eg. cooldown calculation in QuestWorker).

Big do-it-all classes/methods

Big classes and methods are bad for readability, make the code hard to understand for new developers and prevent proper testing. They should be broken down into smaller units with a well designed and documented interface that only exposes the methods needed. Wherever possible, use the composition pattern instead of inheritance.

• Database wrapper (#547)
• WorkerBase: Various game state checks and handling methods should be refactored into smaller helpers.
• QuestWorker: Break out functionalities such as cooldown calculation and rocket stop handling. Create dedicated class for box/quest clearing thread with high-level interface.

Group data together & avoid redundancy

Data that belong together should stay together.

• There's already a named tuple Location; a named tuple Extent should be added to describe a rectangular area. Refactor all usages of plain lat-long coordinates or anonymous tuples to use Location and Extent entities.
• Create a single place to perform geospatial calculations on these entities.
• Consistent handling of timestamps (store in UTC, convert to user's timezone).
• questGen.py (albeit the name sounds more like a script to generate quests) provides a few methods to analyze quest objects. A cleartext quest representation is created and stored in the database, but is redundant data.

[Expl0dingBanana]

In terms of geospatial calculations, the DB rework was moving some of the code into the resource class from the data_manager (2ce7aff). I have not moved geofence_helper yet but its on the todo list. This will also make it easier to add geojson support.