[refactor] Assess the Logger situation and eliminate inefficiency

[jmarrec]

Enhancement Request

Eliminate the use of StringStreamLogSink

 * The use of a `StringStreamSinkLogSink`, for eg for EnergyPlus ForwardTranslator and then **regex parsing** that to derive logMessages is an abomination that should be eliminated.

Detailed Description

Regex parsing is slow, and expensive.

It also poses an extensibility/customization issue: If changing the formatter (the format of the log messages), the parseLogText gets thrown out the window.

Possible Implementation

1. The use of a pattern similar to the one I used in XMLValidator is a possibility
2. Write our end backend sink and override consume to emplace LogMessages is probably the sanest option
   • https://www.boost.org/doc/libs/1_79_0/libs/log/doc/html/log/extension.html#log.extension.sinks

Other issues

• We use a synchronized_feeding backend sink, I think we may need a concurrent_feeding one
• It seems like we may be misusing mutexes.
• This is confusing naming:

  OpenStudio/src/utilities/core/LogMessage.hpp

  Line 43 in dc35f3e

  using LogSinkBackend = boost::log::sinks::synchronous_sink<boost::log::sinks::text_ostream_backend>;

  • boost::log::sinks::synchronous_sink is a frontend sink
  • boost::log::sinks::text_ostream_backend is the backend

Context

List of references:

• Ref Add consistently failing test for warnings/errorsa and document #3912
  • Especially this commit message: 41430bd
• Ref C++ CLI: run.log is huge and missing the runner.registerWarning messages #5030
• ref Adjust LogSink log formatter #5037
• Ref comments on Fix #5030 - C++ CLI: run.log is huge and missing the runner.registerWarning messages #5035 (review)

[shorowit]

Related issue? #4821