feat: network cleanup

[GeopJr]

libsoup can handle caching. Caching entities was more of a headache than helpful (any changes wouldn't reflect or would reflect globally). Caching images in memory for x amount of time is wasteful.

Following tootle discussions it seems that it was implemented because libsoup's wasn't reliable. Tuba migrated to libsoup3 however which might have fixed it.

TODO:

• Check if cache actually works reliably
• Cleanup
• Remove abstract cache altogether
• Cache blurhashes?
• Check reactive entities (like pinning statuses)
• clear cache on close?

fix: #136

[GeopJr]

Libsoup does in fact hit the cache, or at least the logger claims so.

I simplified the API by getting rid of "is_loaded" and instead kept track of it locally. It also takes care of blurhash too. If a blurhash is provided, it will idly decode it and return it if the image hasn't loaded yet.

[GeopJr]

Memory leak in libsoup?
is this expected?
what's going on?

[GeopJr]

I think that last commit fixed #136 🤷 needs more testing

[GeopJr]

... memory leak with FlowBox#bind_model 🤷 used helper functions instead

[GeopJr]

I'll go ahead and merge it. There's no way to find out what might be wrong unless it starts getting used outside of this PR

[LukaszH77]

I used it for some time and it worked fine.

[GeopJr]

It has some problems here and there, especially:

• memory leaks became more prominent
• sometimes it just gives up and doesn't recover - I can reproduce it sometimes on the custom emoji picker, where it will stop midway and then no other images will load at all

Overall this change is actually positive despite its shortcomings. From a user standpoint, it saves on bandwidth by caching images and metadata locally (.cache/Tuba/soup/...) and doesn't clog the main connections by using a separate session for images. From a dev standpoint, it finally gets rid of the whole entity cache headache and should allow me to move forward with other plans.

Thanks for testing it as always 💛🎺