Things have been reordered for no apparent good reason. That just makes the review difficult.

Please provide a detailed test plan. Running the tests is not sufficient as this specific test is not ran by default.

Unless there is a larger plan here, this is just moving away from core without any clear benefit.

Also, adding a test of the java binding to CI would be beneficial so that we can catch these things.

Can we get the java tests fixed before changes are made rather than mix the two together ?

Just port hardening at once. Right now there are no way to check if hardening is ported properly and as this diffs proves, individual steps seems to be broken.

I'm stupid.

This raises also the fact that D2640 was wrong as well.

I'd suggest building a proper sanitation function that escape char properly as this only is susceptible to collisions.

This will generate the same names for C and C++.

Add missing braces

Unless there is something more that append_flag_to_variable is supposed to do, this really sound to me like the kind of contraption you'd find in J2EE. Command line are space agnostics, so it really doesn't matter, and create a level of indirection for nothing.

Please do not change the config to something that's not working as expected. RelWithDebInfo is not working properly yet.

This will fuck up the configuration of everyone. What's the benefit ?

So this clearly raise a lot more question than it answer. This seems to be using a soup of TxId and TxHash, yet the type used is always uint256. I suspect that it's neither because this include merkle path. This seems to make thing more confusing rather than anything else.

If I pass -DCMAKE_BUILD_TYPE=RelWithDebInfo to cmake, I already get these flags. As far as I can tell, this code does nothing more than what cmake already does.

This generates a ton of warning, so there is likely something not correct about what RelWithDebInfo does. It's not -O2 or -g though.

As far as I can tell, building with RelWithDebInfo as build type already use the proper flags for optimization and debug. So at least a good chunk of this patch is just redoing what cmake already does, probably adding bugs in the process.

Look like removing the option from the GUI is the first step here.

The API surface this overs now has increase quite a bit - so the test will be more fragile, it's unclear what side effect of sync_all would cause this test to pass erroneously as this test is not testing how node synchronize, and the fact that marginally faster is not measured makes it a dubious argument at best.

getwalletinfo on an encrypted wallet before and after applying the patch.

Can you remove documentation mentioning support for plateform for which C++14 do not work yet ? Once this is done, I have no problem with that, to the contrary :)

Currently there is a grand total of zero commands that are handled by that framework. I'm not even sure this is required or not, but I'm fairly confident that it's better to have something that handle many the RPC calls rather than have something that could handle them all but handle none in practice. Beside priorities, it is also very possible that other limitation in the current design will be uncovered when actually using it, and any complication of the design will get in the way rather than help.

Please just backport the changes in the test and code associated instead of redoing everything next time.

Why is that better at all to explicit a bunch of things that are not at all related to listtransactions, which presumably is what is checked ?

And improve the test to node rely on a specific node id.