Added Logger which emits a log based on a condition

[dlmarion]

Fixes #4409

[EdColeman]

I added a more general comment on #4409, While this may be useful in some cases, I'm not sure it solves the original issue.

Mainly it seems that this would be hard to use when there is unique information in the message that should be passed along. If we need to treat "issue tablet x" and "issue tablet y" as different messages and not as repeat occurrences of the same message, this seems to want to treat them the same.

[dlmarion]

In f679cd3 I modified the Logger to be based on a generic condition and added a time based implementation that uses a configuration property for the time interval. Like @EdColeman mentioned, not sure how useful this is, but I can envision wanting to log things in a server when some condition is true.

[EdColeman]

Would there be any benefit of allowing the property to be dynamic and stored in ZooKeeper? That would also require a watcher to react to updates - and that is likely to make using this class much harder, basically a server context would likely be required to get the instance / zoo reader / zoo watcher.

It would really complicate the code, but would allow things to be adjusted without restarting services.

The other draw-back would be because this is a general property, setting it will change all instances and it may be really hard to know what they are.

One alternative could be to use log4j and isLevelEnabled to toggle between messages and or message frequency. Something like the following using a count, or could be modified to use a time.

   if(LOG.isTraceEnabled()){
      LOG.trace("always log");
    } else if(LOG.isDebugEnabled() && (count++ % 10) == 0){
      LOG.debug("log every 10");
    } else if(LOG.isInfoEnabled() && (count++ % 100) == 0) {
      LOG.info("log every 100");
    }

Then, using named loggers and standard configuration, the level for that class could be dynamically adjusted at runtime on a named logger basis?

[dlmarion]

The other draw-back would be because this is a general property, setting it will change all instances and it may be really hard to know what they are.

yeah, this is a problem. Currently there is no way to modify the properties of a single server at runtime for debug purposes. I think the standard way to do this is using JMX.

With JShell, manipulating JMX beans becomes easier I think.

[dlmarion]

I had an issue with the implementation regarding AbstractLogger implementing Serializable. I reworked the implementation and removed the Property. I also added @keith-turner's message deduplication implementation to this.

[dlmarion]

These changes were merged into #4558