Lps 51760

@lipusz
Finally had sometime to look into this, and once again it makes me feel sick. I really wish I don't have to read any sharding code. It is just so... ugh... anyway.

Ok, enough complaining, back to the problem,

The problem you saw in 6.2 actually exists in master too, just in a less serious form, so I fixed it in master. It is now your turn to bring it back 6.2 :) (I did my part, have fun on backporting, this is a complex one)

The issue has 2 parts, first 3 commits are for part 1, in https://issues.liferay.com/browse/LPS-47099, I added tx manager to shard, but apparently shard is more broken than that. Its SessionFactory proxy completely broke Spring's inner thread local tx resource binding mechanism. Which is the same cause of https://issues.liferay.com/browse/LPS-48194. But apparently LPS-48194 itself is not enough, shard's code is scatter out, now in this ticket one more hole to fix.

The 2nd part is actually a regression caused by LPS-31817 755e603 and c228769, whiclh is a threadlocal leaking, after calls from there, every following service calls go through wrong SessionFactory. We did not notice this early, because the missing tx manager and broken SessionFactory thing completely covered it up. It is really amazing to see how all the sharding bugs wire up together to produce a "working system".

I tested on master, now cluster with sharding boot up fine, the LockLocalService usage from scheduler is running in new tx correctly.