[BUG] Only 'Param' fields are correctly escaped in JSON logging

Summary

In commit c1962037 we fixed the escaping for Param fields in the logging. But there are code paths were we log strings that can contain characters that need escaping to generate valid JSON and we are not covering those cases.

What is the current bug behaviour?

Double quotes and new lines in log files with json. The logging that generates this is calling LogContext log function lc.log(cta::log::ERR, ErrorFunction + "RSP_ERR_CTA: " + ex.what()); and this is received by the logger () operator as message, not as Params which we actually escape.

void Logger::operator() (int priority, std::string_view msg, const std::list<Param>& params)

{"epoch_time":1729079699.376341725,"local_time":"2024-10-16T13:54:59+0200","hostname":"ctafrontend","program":"cta-frontend","log_level":"ERROR","pid":274,"tid":1153,"message":"In RequestProc::ExecuteAction(): RSP_ERR_CTA: create failed: PostgresConn connection failed: could not translate host name "postgres" to address: Name or service not known

/usr/lib64/libctacommon.so.0(cta::exception::Backtrace::Backtrace(bool)+0x6b) [0x7fc60348241f]
/usr/lib64/libctacommon.so.0(cta::exception::Exception::Exception(std::basic_string_view<char, std::char_traits<char> >, bool)+0x91) [0x7fc603483437]
/usr/lib64/libctardbmspostgres.so.0(cta::rdbms::wrapper::PostgresConnFactory::create()+0x15c) [0x7fc602de1d06]
/usr/lib64/libctardbms.so.0(cta::rdbms::ConnPool::getConn()+0x1bd) [0x7fc6036c8747]
/usr/lib64/libctacatalogue.so.0(+0x2c4fc1) [0x7fc60492ffc1]
/usr/lib64/libctacatalogue.so.0(+0x2cc483) [0x7fc604937483]
/usr/lib64/libctacatalogue.so.0(cta::catalogue::RdbmsArchiveFileCatalogue::getCachedTapeCopyToPoolMap[abi:cxx11](cta::catalogue::StorageClass const&, bool) const+0x7a) [0x7fc6049300b4]
/usr/lib64/libctacatalogue.so.0(cta::catalogue::RdbmsArchiveFileCatalogue::checkAndGetNextArchiveFileId(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cta::common::dataStructures::RequesterIdentity const&)+0x76) [0x7fc60492aaaa]
/usr/lib64/libctacatalogue.so.0(+0x3aa822) [0x7fc604a15822]
/usr/lib64/libctacatalogue.so.0(+0x3ab4f0) [0x7fc604a164f0]
/usr/lib64/libctacatalogue.so.0(cta::catalogue::ArchiveFileCatalogueRetryWrapper::checkAndGetNextArchiveFileId(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cta::common::dataStructures::RequesterIdentity const&)+0x65) [0x7fc604a1589d]
/usr/lib64/libctascheduler.so.0(cta::Scheduler::checkAndGetNextArchiveFileId(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, cta::common::dataStructures::RequesterIdentity const&, cta::log::LogContext&)+0xa3) [0x7fc60573ce7d]
/lib64/libXrdSsiCta.so(cta::frontend::WorkflowEvent::processCREATE(cta::xrd::Response&)+0x353) [0x7fc605d5e1eb]
/lib64/libXrdSsiCta.so(cta::frontend::WorkflowEvent::process()+0x98) [0x7fc605d5dc48]
/lib64/libXrdSsiCta.so(cta::xrd::RequestMessage::process(cta::xrd::Request const&, cta::xrd::Response&, XrdSsiStream*&)+0x323) [0x7fc605cad4b9]
/lib64/libXrdSsiCta.so(XrdSsiPb::RequestProc<cta::xrd::Request, cta::xrd::Response, cta::xrd::Alert>::ExecuteAction()+0x169) [0x7fc605ca9571]
/lib64/libXrdSsiCta.so(XrdSsiPb::RequestProc<cta::xrd::Request, cta::xrd::Response, cta::xrd::Alert>::Execute()+0xd0) [0x7fc605ca6b26]
/lib64/libXrdSsiCta.so(XrdSsiPb::Service<cta::xrd::Request, cta::xrd::Response, cta::xrd::Alert>::ProcessRequest(XrdSsiRequest&, XrdSsiResource&)+0x8f) [0x7fc605ca59fd]
/lib64/libXrdUtils.so.3(XrdScheduler::Run()+0x13a) [0x7fc609c8659a]
/lib64/libXrdUtils.so.3(XrdStartWorking(void*)+0x9) [0x7fc609c86699]
/lib64/libXrdUtils.so.3(XrdSysThread_Xeq+0x38) [0x7fc609c13698]
/lib64/libc.so.6(+0x89c02) [0x7fc60971ec02]
/lib64/libc.so.6(+0x10ec40) [0x7fc6097a3c40]
","instance":"CI","sched_backend":"VFS_Sched"}

What is the expected correct behaviour?

Relevant logs and/or screenshots