implement image cache (pending good replacement policy)

[martensitingale]

For now this doesn't do any on-disk or persistent caching (only within a run), and the cache replacement/evicion policy is not very good.

We still leak memory, but I think at a much reduced rate (I still need to do some testing to verify this and track down the actual leaks themselves).

Avatars and media that have already been requested load immediately from the cache (for example, when sending a toot).

[martensitingale]

Anything you'd like to see before review/merge?

[bleakgrey]

Better clean up policy with image reference counting would be nice, but I can merge this without it in the near future. I just want to fix some other non-memory related bugs first and then I'll move on to this.

[bleakgrey]

Okay, I think the memory usage is a little bit better now, though scrolling down far enough and refreshing still leaves much to be desired. This is not an image cache problem though, the same happens without this commit. So I guess I'll have to investigate what's wrong again, yay.

Something's not being freed and it's really bugging me :/

I think if we could dump the cache contents into the disk and then load on demand I think this could make Soup.Cache redundant.

[alcinnz]

I'd argue flushing a Soup.Cache to disk is easier then you think. As the documentation indicates that if you don't specify a directory (which due to threading issues it encourages you to specify), it has a default.

And a quick skim through the code seemed to show that for the request bodies it is an entirely disk-based. As for the headers, that tiny little bit is in-memory but periodically flushes to disk.

[bleakgrey]

There were no problems with flushing it previously. The problem was that it was constantly rewriting cache files (and then never reading them from the disk) even though they didn't change.