HHH-19551 - Address deficiencies in pessimistic locking

[sebersole]

HHH-19551 - Address deficiencies in pessimistic locking

[Please describe here what your change is about]

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

https://hibernate.atlassian.net/browse/HHH-19551

[gavinking]

Excellent!

[sebersole]

Unless I did something silly, this should be just Oracle failures now. Need to investigate those more.

[sebersole]

About to head out for ~2 weeks of PTO...

About test failures:

1. MariaDB - one test fails (LockedRowsTests#testFindSkipLocked). It does not fail locally if I just run that test or run all the tests in that class or run all the tests in that package or ... makes it hard to debug, but I'll gwt back to it after PTO
2. Oracle - I have not even started digging into these. I'm 100% certain it is because of the way AbstractSqlAstTranslator has LOTS of code specific to Oracle. Handling of for-update was definitely part of that.

Some things I'd still like accomplish here...

1. The main one is to move rendering of the lock fragments from Dialect proper into the LockingSupport impls.
2. A related task is to make LockingSupport.Metadata sensitive to write/read locking. I think tjis will be needed for (1).
3. Integrate support for LockTimeoutType#CONNECTION into the acquisition of locks when performing find/lock/refresh operations. I've implemented ConnectionLockTimeoutStrategy for quite a few dialects already, which handles the actual setting/resetting.
4. Adjust design of JdbcOperation to simply be a concept of something that needs to be performed via JDBC. Currently it implies a single statement. Ultimately I want this to be open-ended and mean 1-or-more statements. This would allow grouping all the SQL needed for locking into a single JdbcOperation and combine ConnectionLockTimeoutStrategy, follow-on locking as well as the main query.

WRT (2), currently I have:

public interface LockingSupport {
	Metadata getMetadata();

	...

	interface Metadata {
		LockTimeoutType getLockTimeoutType(Timeout timeout);
		RowLockStrategy getReadRowLockStrategy();
		RowLockStrategy getWriteRowLockStrategy();
		...
	}
}

public class Dialect {
	...
	LockingSupport getLockingSupport();
}

Thinking instead of something like:

public interface LockingSupport {
	Metadata getMetadata();

	...

	interface Metadata {
		LockTimeoutType getLockTimeoutType(Timeout timeout);
		RowLockStrategy getRowLockStrategy();
		...
	}
}

public class Dialect {
	...
	LockingSupport getWriteLockingSupport();
	LockingSupport getReadLockingSupport();
}