[vfs][imagecache] Separate 'image://' VFS protocol from TextureCache

[rmrector]

Description

Create a strongly-typed ImageFileURL to manage image files, particularly for special images and their options.

Mostly the same functionality but some small changes:

• remove size=thumb image option that mostly just doubled the cache size in the picture browser
• change chapter://nfs://...mkv/2 image path to image://video@nfs%3A%2F%2F...mkv/?chapter=2 to match all other generated image paths. The old images will stay in the texture cache for now.
• Isolate resizing options (width, height, scaling_algorithm) to just the HTTP endpoint for resizing. Before they could technically be used for image URLs from anywhere. Scaling algorithm config in AS.xml is unaffected.
  • we can use the idea further in the future, but it shouldn't be in the cached URLs like these were.

Commits are separated into steps of the refactoring.

Motivation and context

Separate, organize, and clarify some functionality around images, special images, and image caching.

Enable future work: in the future, path options could be used to change current embedded video image loader that uses a "dynamic" special type like video_poster and video_fanart to a static type like video_embed with option embed_type=fanart - that gives us an easy place to support more embedded images and special type is more suitable to be an enum.
I'm also curious if the generated video image loader is accurate enough for repeatable bookmarks: video special type with an option like time_in_seconds=600.66.

How has this been tested?

Dogfooding for a couple weeks, and I moved the few tests from the previous implementation.

What is the effect on users?

Potential mild speedup in the picture browser when images aren't cached yet, and video chapter images will regenerate once after this when viewed in the chapter browser.

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• Student submission (PR was done for educational purposes and will be treated as such)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[rmrector]

jenkins build this

[rmrector]

jenkins build this please

[rmrector]

jenkins build this please

[rmrector]

• PR25063-0002-2d12fa0d3b-don-t-pass-preferred-size-to-last-.diff

That is code I removed, I'm not formatting it.

[rmrector]

Any thoughts on this? It's mainly refactoring and not very interesting, I'll merge it soon if there are no objections.

I just started dogfooding a class named CImageCacheCleaner as a followup, if that sounds any more interesting.

[jenkins4kodi]

I've made some formatting changes to meet the current code style. The diffs are available in the following links:

• PR25063-0002-e8906a9cf6-don-t-pass-preferred-size-to-last-.diff

For more information please see our current code style guidelines.