ProxyClientBase: avoid static_cast to partially destructed object #127

This is a bugfix that should fix the UBSan failure reported https://github.com/chaincodelabs/libmultiprocess/issues/125

In practice there is no real bug here, just like there was no real bug fixed in the recent "ProxyClientBase: avoid static_cast to partially constructed object" change in https://github.com/chaincodelabs/libmultiprocess/pull/121. This is because in practice, ProxyClient subclasses only inherit ProxyClientBase state and do not define any state of their own, so there is nothing bad that could actually happen from static_cast-ing a ProxyClientBase pointer to a ProxyClient pointer inside the ProxyClientBase constructor or destructor.

However, using static_cast this way technically triggers undefined behavior, and that causes UBSan to fail, so this commit drops the static_cast by making ProxyClient::construct() and ProxyClient::destroy() methods into static methods taking a ProxyClientBase& argument instead of instance methods using *this.

Fixes #125

This PR should be a simpler, more robust alternative to a previous for the same bug implemented in #126.

That did the trick! https://github.com/bitcoin/bitcoin/actions/runs/12805094945/job/35700776707?pr=30975

cc @TheCharlatan

lgtm ACK

PoxyClient subclasses only inherit ProxyClientBase state and do not define any state of their own

Seems like this is the correct thing to do in that case anyway.

Seems like this is the correct thing to do in that case anyway.

Yeah I really did not like the previous fix in #126, but this fix is not too bad. The thing I still don't like about this fix is that it makes construct/destroy different than other methods, instead of treating them the same as other methods but just calling them automatically on the client side.

But unfortunately there doesn't seem to be a good way to call construct/destroy automatically from with ProxyClientBase class without using static_cast or turning them into static methods. I think c++23 with http://wg21.link/P0847 might be able to help with this in the future, but i'm not sure.