Add type hints to db and constants modules

[abhiraj75]

Adds type annotations to wp1/db.py and wp1/constants.py as part of the incremental type hinting effort (#1017).

Changes:

wp1/db.py: Added type hints for connect() function signature, module-level variables, and local variables.

wp1/constants.py: Added type hints for all module-level constants, including bytes annotations for GLOBAL_TIMESTAMP and GLOBAL_TIMESTAMP_WIKI, and dict[str | bytes, str] for CONTENT_TYPE_TO_EXT.

[abhiraj75]

@audiodude you mentioned that type hinting can help find bugs , this is a small example:
ENV == ENV.DEVELOPMENT compares against the enum instance's own attribute instead of the class member. Changed it to ENV == Environment.DEVELOPMENT. It works either way at runtime, but the original is misleading.

[audiodude]

Thanks for the PR, but I feel like most of these are superfluous.

Can't mypy (or whatever) figure out that:

ZIM_FILE_TTL: int = 2 * 7 * 24 * 60 * 60  # 2 weeks

Is an int? Won't we already get a type failure if we try to reassign a string to it? I don't know the answer, I'm genuinely asking.

I can definitely see the usefulness for complex types like dicts:

CONTENT_TYPE_TO_EXT: dict[str | bytes, str] = {
    "text/tab-separated-values": "tsv",
    b"text/tab-separated-values": "tsv",
    "application/vnd.ms-excel": "xls",
    b"application/vnd.ms-excel": "xls",
}

Since "anything" can go into a dict and we want to preserve a strict mapping.

[abhiraj75]

Yes , pyright can infer simple types from assignments. We should probably trim down to a specific set of annotations (the useful ones) such as dicts, bytes vs str (removing ambiguity as you initially mentioned) , function signatures. etc. Makes sense. Thanks !
Will update .

[abhiraj75]

@audiodude Trimmed down to the specific set of annotations