Refresh fhir-persistence-schema parameter-names.properties

[lmsurpre]

Is your feature request related to a problem? Please describe.
While performing a large reindex, we noticed a few deadlocks and at least one was related to a search parameter that should be in our default (pre-populated) parameter_name table, but isn't: communication:text

This list was originally created by ingesting a bunch of data with the default config and then grabbing all of the parameter names. However, our search parameter processing has likely evolved since then.

Describe the solution you'd like
Repeat the process for generating parameter_names.properties so that a fresh db will be pre-populated with the most accurate list of built-in parameter names possible.

Describe alternatives you've considered

Acceptance Criteria

1. GIVEN [a precondition]
   AND [another precondition]
   WHEN [test step]
   AND [test step]
   THEN [verification step]
   AND [verification step]

Additional context
If we do this before FHIR R4B, we'll need to do it again after that.

[lmsurpre]

steps:

1. load all the search parameters (check out ParametersHelper in fhir-serarch)
2. cross-check that list against parameter_names.properties

[lmsurpre]

for QA just hook up to the database after provisioning and confirm the new parameters exist under parameter_names

[lmsurpre]

when we looked at this together a while back, I thought I saw communication:text on the list of parameter_names.properties. however, looking again, I think that was just a local edit that I had...I still do not see the search parameter in the list and I still think it should be there because this search parameter is defined on the Practitioner resource, its of type "token", and it indexes an element of type CodeableConcept.

[lmsurpre]

@PrasannaHegde1 I think we need to redo the exercise of looking for missing parameters.

minimal-json.txt includes json/complete-mock/Practitioner-1.json and posting this example to the server should have resulted in the creation of this communication:text search parameter

locally, when I turn tracing up, i see the following message which indicates that it was not included in the list of parameter names that we pre-populate:

PlainParamVal 1 resolveParameterNames: sorting unresolved names
PlainParamVal 2 org.linuxforhealth.fhir.persistence.params.database.PlainParamValueProcessor resolveParameterNames fetching parameter_name_id for 'communication:text'
PlainParamVal 2 assigned parameter_name_id 'communication:text' = 20859

I'm not sure why we wouldn't have noticed that one the first time we did this exercise, but I'm worried there might be others like it.
The "best" thing to do would probably be to upload all complete-mock examples instead of just the minimal set.
That can be accomplished by modifying <fhir-server-test.index>MINIMAL_JSON</fhir-server-test.index> to <fhir-server-test.index>GENERATED_JSON</fhir-server-test.index> in fhir-parent/pom.xml (or by modifying R4ExampleServerTest.java directly) and then checking the PARAMETER_NAMES table against the list in parameter_names.properties again.

[lmsurpre]

there are no more known search parameters from the core spec which aren't prepopulated to the db now