Btwxt error handling

[chipbarnaby]

Description

Motivation: capture and report btwxt error messages.

Implemented several classes derived from Courier. Updated all btwxt uses.

No results changes. No documentation changes.

[nealkruis]

Here's how I would design this:

In hvac.h:

class RSYSBtwxtLogger : public Courierr::Courierr
{
public:
	explicit RSYSBtwxtLogger(std::string rgi_name_in, RSYS* pRSYS_in) : rgi_name(rgi_name_in), pRSYS(pRSYS_in) {}
	void error(const std::string_view message) override { pRSYS->oer(format_message(message)); }
	void warning(const std::string_view message) override { pRSYS->oWarn(format_message(message)); }
	void info(const std::string_view message) override { pRSYS->oInfo(format_message(message)); }
	void debug(const std::string_view message) override {  pRSYS->oInfo(format_message(message));  }
private:
	RSYS* pRSYS;
	std::string rgi_name;
	std::string format_message(std::string message) { return fmt::format("btwxt '{}' -- {}", rgi_name, message)}
}

and I'd make a similar one for CHDW. You could even put rgi_name and format_message into a baseclass that these are both derived from. That way you don't have to deal with the callbacks and casting.

[nealkruis]

Consider changes. I won't push too hard on my suggestions if you want to merge anyway.

[nealkruis]

My thought is that void* context and a MsgCallbackFunc* are very "C". There is a lot of indirection for people trying to read the code. My preference would be to make a new class for each different context with a specific forward_message override.

[chipbarnaby]

1. Don't want 10 essentially identical implementations. Maybe there is a way to template this to make it clearer? In any case, there is going to be a "callable" somewhere aka a pointer.
2. Additionally, what is wrong with C? CSE is small and fast, partially due to using lots of C stuff.
3. I recently learned about a "dependency injection" scheme which might be very useful here.

[nealkruis]

Is this still needed?

[chipbarnaby]

Not right now, but I made it and tested it. It is tiny and likely useful soon given the ever-growing interaction with other libraries. So I say leave it.

[nealkruis]

see previous question.