Reevaluate custom lru_cache decorator

[VannTen]

thoth/storages/graph/postgres.py#L210 contains a implementation of lru_cache
for methods.
This seems like something which should already exists in a library.

Potential candidates (cachetools, functools, methodtools)

Potentially relevant

https://stackoverflow.com/questions/33672412/python-functools-lru-cache-with-instance-methods-release-object
tkem/cachetools#106
python/cpython#64058

Refs

Introduced in commit 06a7722 ("performance reasons")

/kind cleanup
/triage needs-information
/priority backlog

(That's part of my exploration of the storages codebase while trying to fix mypy
errors in #2674, leaving that here for future reference)

[VannTen]

/sig stack-guidance

[mayaCostantini]

I think the goal of this custom decorator was to avoid eventual memory leaks caused by the functools implementation? Why should we replace it with an implementation from a library?

[VannTen]

I think the goal of this custom decorator was to avoid eventual memory leaks caused by the `functools` implementation?

That's also what I understand. The point of the issue is to assess is a opensource python lib already implements this (or would accept a contribution for adding it, but that's a higher bar)

Why should we replace it with an implementation from a library?

lru_cache being a general concept which is useful in many other context than thoth, in an ideal world it would be in a opensource community python library. More pragmatically, it would reduce our codebase and maintenance load.

[sesheta]

Issues needing reporter input close after 60d,

If there is new input, reopen with /reopen.