Duplicate values for one resource in xx_resource_token_refs

[punktilious]

Describe the bug
The xx_resource_token_refs table contains duplicate entries. Although this doesn't impact the results of FHIR search interactions, it does lead to increased storage costs:

fhirdb=> select parameter_name_id, common_token_value_id, logical_resource_id, composite_id from fhirdata.patient_resource_token_refs where
parameter_name_id = 20423 and logical_resource_id = 458590;
 parameter_name_id | common_token_value_id | logical_resource_id | composite_id 
-------------------+-----------------------+---------------------+--------------
             20423 |                   886 |              458590 |             
             20423 |                   886 |              458590 |             

The same is true for xx_str_values.

Parameter tables are heavily indexed, so having duplicates here is significant.

Environment
Which version of IBM FHIR Server? 5.0.0

To Reproduce

1. Build a fresh schema
2. Run the system integration test suite
3. Query the database and look for parameter tables with duplicate entries

Expected behavior
Parameter tables should not have duplicates. Note, some parameter values may be stored more than once if there are composites involved, but a parameter value should not be stored more than once where composite_id is null.

Additional context
N/A

[punktilious]

Deduplicating the parameter values before we store them requires visiting all the ExtractedParameterValue values and converting them into values we intend to store in the database. This deduplication can't be done at the ExtractedParameterValue level because an extracted value may contain multiple values.

This process is already performed by the remote-index client, so I propose that we do some refactoring and replace the current parameter persistence code with the newer (hopefully faster) remote index implementation. This will allow all parameter values to be collected as part of the transaction and should lead to improved throughput.

[punktilious]

This refactor requires a new project is created. The new project will be shared by both fhir-persistence-jdbc and fhir-remote-index. This avoids polluting fhir-persistence-jdbc with Kafka stuff, and fhir-remote-index with all the dependencies required for fhir-persistence-jdbc.

[punktilious]

The new search parameter persistence code in fhir-persistence-params supports both PostgreSQL and Derby. For now, Db2 will use the old mechanism.