Protecting the LockableResourcesManager from Races

[bbara]

Hey guys,

this PR should protect the resources member of the LRM to avoid races (like #149). Some of the locks might be a little bit overprotective but I think with ephemeral resources the member will become more volatile and therefore also more vulnerable to races.

The PR is extending the current synchronization by including the scope of returned references. As synchronized should behave reentrant/recursive, no deadlocks should be possible.

If further stuff is required to merge it, please feel free to tell me. If I find time, I will also attach a test that tries to provoke such an error.

BR, BB

[famod]

@bbara Any chance to resolve the conflicts? Thanks!

[bbara]

@famod of course :)

I removed the reformat commit, @TobiX maybe run mvn fmt:format one time.

[TobiX]

FWIW, this doesn't look like the way to go: LockableResourcesManager should be made thread-safe internally, not by sprinkling synchronized liberally all over the code. Its locking behaviour is already too broad and I'm leaning more into pulling the locks tighter around a certain "core", not by expanding the locks until you lock almost every class in the whole plugin...