Create a dataclass for version info

[sirosen]

@ericholscher and I briefly discussed this at the PyCon US Sprints.
This some basic backlog cleanup.

I have tests passing for me locally except for some which rely on rclone -- I didn't feel like installing that, so I'm just trusting CI for now.

closes #7798
closes #10936

I only noticed #10936 after I finished this. I named and placed the class slightly differently and didn't make some of the formatting changes which that version did (because things have updated anyway).

---

Convert from fixed-shape dicts to a dataclass. Preserve almost all code semantics identically -- e.g., variable assignments in readthedocs.api.v2.utils may be micro-optimizations which could be important.

The only intentional semantic change included here (other than the change in types) is in readthedocs.projects.tasks.mixins, where a list comprehension is replaced with a generator expression.

[ericholscher]

This looks good to me, but will ping @stsewd as well here, since I know there were some plans for a larger refactoring. This feels like a nice improvement over the current situation tho, so I'd be 👍 on merging and then refactoring more later.

[stsewd]

Since we use celery with the json serializer in production, this breaks builds (we should probably use that same serializer in tests).

EncodeError: Object of type ProjectVersionInfo is not JSON serializable

Doesn't look like there is a clean solution to just change the dataclass to make it json serializable. Named tuples are json serializable, but not sure if they can be serialized back, as they are serialized as a list.

Also, doesn't look like this change has anything to do with #10963.

[sirosen]

Ah, whoops! That's definitely the wrong issue linked. I'll correct not only the PR comment but the commit message (so that GitHub won't auto-close an unrelated issue). There is a PR which addressed this same issue, but I must have fat-fingered the number for it somehow.

Regarding serialization, if the data is being passed around as JSON, I have some notion of how to approach it. I would not setup a custom JSON encoder -- it only real solves the encoding side, not decoding, and I don't think there's a simple path to resolve that asymmetry.
My preference would be to give the dataclass an additional pair of methods:

@dataclasses.dataclass
class ProjectVersionInfo:
    def to_dict(self) -> dict[str, typing.Any]:
        return dataclasses.todict(self)

    @classmethod
    def from_dict(cls, data: dict[str, typing.Any]) -> typing.Self: ...

so that it encapsulates the JSON-safe-dict encoding and decoding logic. (from_dict can have explicit checks on the data, rather than the potential for TypeErrors and whatnot from ProjectVersionInfo(**dict_data))

I assume the tests are pickling? I'll sniff around and see if I can find the appropriate module(s).

---

I'll address all of the above this evening or in the next couple of days, when I'm not on the clock for work.

[sirosen]

I edited to update. I had transposed digits; the relevant PR I meant to reference is #10936.