Add fetchart typing

[wisp3rwind]

Add typings to fetchart. there are a few rough edges requiring cast and enums could be better represented, but this is a start.

[snejus]

Mostly looks good. Added a couple of small comments, mentioned the risks of using naked asserts, and mentioned three issues in lines 1476-1490 that non-strict mypy is not flagging for some reason.

[wisp3rwind]

Ok, I think I addressed everything. I went quite far in trying to express things via types, at least for this being Python.

There's one more thing that this reminded me of (but which is out of scope in this PR): At some point, the ImageAction should really be turned into a bitfield/flags rather than an enum (also, this enum might even move into the artresizer module), cf. #4133 (comment)

[wisp3rwind]

I've just seen #5152, which I've completely missed up to now, and which is badly conflicting with what I'm doing here. However, while it's great that there's some momentum on the issue that #5152 tackles, I'm not convinced of the approach.

In contrast, what I'm doing here would fit nicely with eventually pushing the multiple-action image conversion completely to the artresizer.

[snejus]

Types look great! Added a few minor comments and included a consideration regarding the Candidate class design

[snejus]

Regarding the design: it seems like Candidate has no other use except for running validation. The attributes that the object has are only required until the end of the validate method, at which point it becomes ValidatedCandidate and becomes either ExactCandidate or InexactCandidate. A couple of points here

1. It looks to me this should be just a function or a method instead which does not need to hold any state. See the Middle Man code smell
2. Candidate is the main guy here so I feel like it should be made a bit more relevant by keeping all related logic.
3. Judging by the class names, the difference between ExactCandidate and InexactCandidate may not be significant enough to justify the need to create two classes.

All in all, I think the validation looks like a great use case for a factory method like

class Candidate:
    @classmethod
    def from_match(cls, _log: Logger, source: ArtSource, ...) -> Self:
        # validate
        ...
        return cls(source=source, path=path)  # return a new Candidate

This drops the need for the ValidatedCandidate since now Candidate must be valid in order to be created.

The resize method from InexactCandidate can be a method on Candidate - which does nothing if the size already meets the expectations.

[wisp3rwind]

The point of the ExactCandidate/InexactCandidate split was to avoid assertions in their .resize() method (since only for InexactCandidate we always know the size). I think encoding that using the type system does require different types (or generics).

I'll see what I can achieve by refactoring Candidate.

[wisp3rwind]

You might be right that this can be simplified: We split the process of finding, downloading, validating and resizing art into separate function, but only ever run them one after each other anyway.

[snejus]

You might be right that this can be simplified: We split the process of finding, downloading, validating and resizing art into separate function, but only ever run them one after each other anyway.

In such case, maybe a couple of @classmethods could be a good candidate (pun intended)?

[Dr-Blank]

I've just seen #5152, which I've completely missed up to now, and which is badly conflicting with what I'm doing here. However, while it's great that there's some momentum on the issue that #5152 tackles, I'm not convinced of the approach.

In contrast, what I'm doing here would fit nicely with eventually pushing the multiple-action image conversion completely to the artresizer.

The only issue with pushing multiple flags is that image operations are not mutually exclusive. Reformating affects size.

For e.g., the size of the PNG image changes drastically when converted to JPEG. So if my configuration is to always use JPEG images of max size 5 MB, the flags for a 15 MB PNG would be [REFORMAT, RESIZE] but after reformat if the size would drop to below 5 MB, the RESIZE would be unnecessary, hence a evaluation is needed after every step.