Isolate and externalize SOLR functionality

[anthonysena]

This issue is based on discussion in the Atlas/WebAPI Developer Subteam from 2/7/2023 and is aimed as describing the desired state based on changes in #2196.

Currently, WebAPI has support for optionally using Apache SOLR for vocabulary search (#1091). When this functionality was introduced, we wanted to have a way for people to install/configure/manage SOLR for vocabulary search while also having the fallback to the default vocabulary search driving by SQL queries against the vocabulary daimon of a CDM.

It has been noted by @alex-odysseus, that the current implementation has a few challenges and it may be advantageous to externalize the SOLR functionality for WebAPI to a separate Java project (component). Some of the challenges include:

• The SOLR Java components are automatically installed when you install WebAPI, even if you are not using SOLR functionality. This has implications on security patches related to SOLR - we'd want to patch these for installations that are using SOLR.
• The current implementation in WebAPI is too concrete leading to implementation such as:

WebAPI/src/main/java/org/ohdsi/webapi/vocabulary/VocabularySearchServiceImpl.java

Lines 26 to 36 in 8adbdd3

	@PostConstruct
	protected void init() {
	// Get the SOLR cores list if enabled
	if (solrSearchClient.enabled()) {
	try {
	availableVocabularyFullTextIndices = solrSearchClient.getCores();
	} catch (Exception ex) {
	log.error("SOLR Core Initialization Error: WebAPI was unable to obtain the list of available cores.", ex);
	}
	}
	}

In the code above, the PostConstructor for the Java bean is used to determine which implementation to use - even if SOLR is not configured, it will error out which is misleading when reviewing logs. Furthermore, it locks the implementation into 2 search providers only.

Proposed state

As a first step, we'd like to change WebAPI such that the use of SOLR is driven by a profile that is used when compiling the WebAPI.war. In this way, the SOLR dependencies are then injected at compilation time and not at run time. To do this, the interfaces and implementation would be moved to an isolated part of the WebAPI code base (as is the intent of #2196). Later, this functionality would move to an external Java library.

Hoping this captures the discussion @chrisknoll, @alex-odysseus

[anthonysena]

Bringing over some additional next steps for v2.14 based on comments from @ssuvorov-fls:

next steps for 2.14:

Creating two repositories:
1.1. Repository for common classes which will be used in both webapi and solr modules
This repository will include the following classes:
org.ohdsi.webapi.vocabulary.Concept;
org.ohdsi.webapi.vocabulary.SearchProviderConfig;
org.ohdsi.webapi.vocabulary.SearchProvider;
org.ohdsi.webapi.info.ConfigurationInfo - this classes can be excluded but in this case we won't be able to get information about Solr config parameters
1.2. Repository for solr modules
org.ohdsi.webapi.vocabulary.solr.SolrSearchProvider;
org.ohdsi.webapi.vocabulary.solr.SolrSearchClient;
org.ohdsi.webapi.vocabulary.solr.SolrConfigurationInfo;

Adding profile to pom.xml in WebAPI