feat: Extract env/system/context config logic into LyoConfigUtil

[berezovskyi]

Description

As you know, https://blog.sonatype.com/a-new-0-day-log4j-vulnerability-discovered-in-the-wild is a big problem for the ecosystem. We are not using v2 of Log4j and are not affected but I wanted to take a bit of time to fully remove remnants of Log4j use in Lyo. As you know, Lyo uses SLF4J API in all SDK libraries and SLF4J + SimpleLogger in the webapps we ship.

Another thing this PR does is introduce the org.eclipse.lyo.core.utils.marshallers.LyoConfigUtil class with helper methods to scan the environment for a property. For example, if you are looking for the port property in the org.eclipse.lyo.oslc4j.core.servlet.ServletListener instance, we want to check these places in the order of priority:

1. LYO_PORT environment variable. This is the new override mechanism for containerized environments.
2. org.eclipse.lyo.oslc4j.core.servlet System (JVM) property. This is the old override mechanism for multitenant application server environments.
3. org.eclipse.lyo.oslc4j.core.servlet Servlet Context parameter. This is the default configuration mechanism for Lyo.

org.eclipse.lyo.core.utils.marshallers.LyoConfigUtil#getOslcConfigProperty does exactly that, while org.eclipse.lyo.core.utils.marshallers.LyoConfigUtil#getOslcConfigPropertyNoContext represents a fallback mechanism only looking in (1) and (2) in case it must be invoked from a place where a ServletContext reference is not available.

However, after getting the oslc4j-registry app to run, I realized it only contains a CF only on a ServiceProvider level. My old impression was that it allows to run a single registry where mutliple SP Catalogs can be registered with the "registry" SP Catalog. In light of this discovery, I propose to mark oslc4j-registry for removal in Lyo 5.0. In current form, it's not much more than a demo app and a default output from Lyo Designer has more user-friendly look and features out of the box.

Finally, oslc4j-wink seems to have only 2 useful things:

• OslcResourceShapeResource for reuse by Wink-based OSLC Servers. We don't support Wink any more and Lyo Designer supports much more feature-rich shape resource support (e.g. Shape HTML tables like in the OSLC specs, even for custom resources).
• org.eclipse.lyo.oslc4j.client.OslcRestClient. This client was long replaced by the (now obsolete) org.eclipse.lyo.client.oslc.OslcClient. Modern apps should use one of the new clients via the org.eclipse.lyo.client.IOslcClient interface.

With this in mind, I propose to mark the org.eclipse.lyo.oslc4j.client.OslcRestClient deprecated immediately (done in this PR) and also schedule oslc4j-wink for full removal from Lyo in 5.0.

Checklist

• This PR adds an entry to the CHANGELOG. See https://keepachangelog.com/en/1.0.0/ for instructions. Minor edits are exempt.
• This PR was tested on at least one Lyo OSLC server or adds unit/integration tests.
• This PR does NOT break the API
• maven enforcer rule added to <exclude>log4j:log4j</exclude>

[berezovskyi]

Discussed with Jad. Andrew will

• move the config code to org.eclipse.lyo.oslc4j.core.OSLC4JUtils
• remove the registry and wink modules

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
7 Code Smells

0.0% Coverage
0.0% Duplication

[berezovskyi]

Fails due to #284, we should instead move this code to a new module, e.g. org.eclipse.lyo:lyo-server-utils because we don't want core utils to bring back the Servlet dependency.