Stop caching MerginProjects, since that's now done by the client library

[dvdkon]

This PR is a follow-up to MerginMaps/python-api-client#283, which moved the caching into the client library.

This fixes a bug where due to using stale metadata in one MerginProject instance, the initial init and sync was unable to complete.

[wonder-sk]

I think I get a bit scared of doing the caching directly in the python api and letting db-sync rely on that 😅

My understanding is that within the context of db-sync, the metadata do really only get invalidated in two possible cases: after a pull -or- after a push (if there is a version change). I wonder if we couldn't just add an explicit "invalidate mergin project" function call after those actions, that will make sure to release existing MerginProject from the cache - what do you think? (this would also avoid the need to create a new python-api-client release, which has a different release cycle 🙂) - what do you think @dvdkon ?

[dvdkon]

My understanding is that within the context of db-sync, the metadata do really only get invalidated in two possible cases: after a pull -or- after a push (if there is a version change). I wonder if we couldn't just add an explicit "invalidate mergin project" function call after those actions, that will make sure to release existing MerginProject from the cache - what do you think?

I think that's correct, but I'd rather not rely on the invalidation function being properly called every time, I think it could lead to sneaky hard-to-debug issues. If releasing new versions of both projects isn't insurmountable, I'd rather use the "one MerginProject per directory" solution - you can't have desync issues if you only ever keep one copy of the data :)

[wonder-sk]

On hold (see #170)