Better permanent solution for QosAlertGenerator which shall not modify the logging configuration at runtime

CONTROLLER-1845 documents massive confusion, and significant total time lost by far too many busy people, until skitt found out that:

(...) this is caused by the Pax Logging configuration file having the wrong contents, so the logs aren't stored in the Karaf log file. Jamo reproduced this, and had a configuration file which only contained the lines from qosservice.cfg. So it seems that QosAlertGenerator in NetVirt is involved — it rewrites the configuration file...

and in further discussion tpantelis mentions that:

assume it's getting overwritten with log4j settings instead of log4j2 (...) seems odd for QosAlertGenerator to add fixed logging configuration in code at runtime, usually such configuration is set up on deployment if desired. I don't know the history of this but perhaps we should consider removing it.

While it may be possible to "fix up" the content of that qosservice.cfg file (log4j2 format?), I have to very strongly agree that this seems like a completely crazy approach to begin with.

https://git.opendaylight.org/gerrit/#/c/74496/ therefore removes the code that used to do runtime logging change in QosAlertGenerator to unblock CONTROLLER-1845.

This issue is to discuss if and how a better solution can be re-implemented in a future follow up change to the removal.