reindex operation should lock logical_resources_ident with select for update

[punktilious]

Describe the bug
The reindex operation is vulnerable to a race condition if the resource is updated after the reindex read is performed.

Environment
Which version of IBM FHIR Server?

To Reproduce
Steps to reproduce the behavior:

Concurrent resource updates at the same time as concurrent reindex operations on overlapping resources.

Expected behavior
The reindex operation must lock the logical_resource_ident record before inserting the new parameters.

Additional context
The select for update needs to use the resource_type_id and logical_id (the PK for logical_resource_ident). Because the reindex operation is driven by logical_resource_id, there must be a read against logical_resources first to get these values. The logical_resource_ident record can then be locked and the resource payload read without risk of a race condition.

[lmsurpre]

QA:
set TRACE_SPEC to "com.ibm.fhir.persistence.jdbc.dao.ReindexResourceDAO=fine" and confirm we're seeing the Locking (select for update): for both client-driven and server-driven reindex.
Server-driven reindex does locking elsewhere.

[lmsurpre]

I set the TRACE_SPEC and I confirm that I see the log message about locking for each resource that gets re-indexed using both server-driven reindex (where we pass a tstamp) and client-driven reindex (where we pass a list of index ids).

One thing I noted is that we perform the locking irregardless of whether the parameters hash matches (both client and server-driven reindex)

@punktilious if the above is what we expect, then I think this is working.