End-to-end automation test for reindexing

[lmsurpre]

We released 4.5.0 without catching a reindex bug that prevented the correct migration of data: #1742

To prevent that from happening again, we should include a test in our CI pipeline which does the following:

1. writes a resource / some set of resources (maybe the Basic ones used in our persistence search tests?)
2. changes the configured set of search parameters (maybe add the corresponding extension-search-parameters for the search tests?)
3. invoke reindex (as needed until everything is refreshed)
4. performs a search / set of searches to verify the data is returned as expected

For even greater assurance, we could extend the existing db migration test to do the following:

1. deploy an older version of the schema
2. write a resource / some set of resources (maybe the Basic ones used in our persistence search tests?)
3. apply the schema migration
4. (optional) adjust the search parameters slightly
5. invoke reindex
6. perform a search to verify the expected resources are still returned

UPDATE: we probably don't need to tie the re-index test to the migration test. Having them as two separate tests should be sufficient.

[lmsurpre]

Does https://github.com/IBM/FHIR/pull/2107/files sufficiently cover this one?

[prb112]

Does https://github.com/IBM/FHIR/pull/2107/files sufficiently cover this one?

Currently, it's just a sniff test. Does it work with one resource.
If you are OK, we can rock with one sniff test (across derby, postgres, db2) or we can add a small loop of say one hundred.

Also, to be a true test, we would create a set of search parameter, search find the resource by search parameters related to the types, and then change the search parameters (not type) to a new FHIR Path, and show they are not retrievable by the search parameter.

[lmsurpre]

OK, thanks Paul. Lets leave this one open then for the testing improvements you mention.

[d0roppe]

Tests are part of the integration tests that run as part of the build now. closing issue