Remove properties cache and token-based matching

[ppkarwasz]

The PropertiesUtil class preemptively caches lookups for all known keys from enumerable property sources.
On my Debian system a JVM has around 60 among environment variables and system properties, which causes PropertiesUtil to perform around 60 lookups for each of the 3 standard property sources. Most of these properties have nothing to do with Log4j.

On the other hand all Log4j artifacts use no more than 100 configuration properties and the results of most of those calls are cache in static fields.

This PR removes the property value caches used by PropertiesUtil.
The change should have no noticeable impact on the loading time of Log4j Core, while at the same time simplifies the system.

As remarkable side effect token-based matching of property names is no longer supported. This mean that, e.g. a system property like log4j2.asyncLoggerRingBufferSize can be written:

• as AsyncLogger.RingBufferSize (pre-2.10 legacy form),
• as log4j2.asyncLoggerRingBufferSize (2.10 canonical form).

No other forms (e.g. log4j.async.logger.ringBuffer.size) are accepted.

Note: We never documented that we support token-based matching. See current Configuration Properties documentation.

[vy]

The change should have no noticeable impact on the loading time of Log4j Core, while at the same time simplifies the system.

Reminder: If the goal is simplification, we can even replace all existing sort-on-add lines with a single sort-while-iterating.

As remarkable side effect token-based matching of property names is no longer supported. This mean that, e.g. a system property like log4j2.asyncLoggerRingBufferSize can be written:

• as AsyncLogger.RingBufferSize (pre-2.10 legacy form),
• as log4j2.asyncLoggerRingBufferSize (2.10 canonical form).

No other forms (e.g. log4j.async.logger.ringBuffer.size) are accepted.

Note: We never documented that we support token-based matching.

I would have expected following properties (collected from the rel/2.23.1 site) to not work anymore:

• log4j2.enable.direct.encoders
• log4j2.jmx.notify.async

Though they still do work. Would you mind explaining why, please?

[ppkarwasz]

The change should have no noticeable impact on the loading time of Log4j Core, while at the same time simplifies the system.

Reminder: If the goal is simplification, we can even replace all existing sort-on-add lines with a single sort-while-iterating.

I dropped a comment in there. Replacing the locks and the ArrayList with a concurrent set introduces only a couple of µs to the startup process, so should be negligible.

I applied the suggested change in 28b46de.

I would have expected following properties (collected from the rel/2.23.1 site) to not work anymore:

* `log4j2.enable.direct.encoders`

* `log4j2.jmx.notify.async`

Though they still do work. Would you mind explaining why, please?

These are the correct pre-2.10 forms of these properties, that is why they work.

I don't plan for this change to be so drastic as to disable configuration properties that were documented in previous Log4j Core versions. I only want to remove those that were not documented, but worked by some chance, e.g. log4j2.jmx.notifyAsync.

[ppkarwasz]

@vy,

I did non-trivial changes in 28b46de. Can you review this again?