[0.11] dbwrapper: Detect obfuscation

[maflcko]

Replaces #6919.
Fixes #7258.
Implements #6613 (comment).

[pstratem]

concept ACK fa24941

[luke-jr]

Won't this detect the no-op obfuscation too? That wouldn't be a good idea...

[pstratem]

@MarcoFalke luke-jr is right you need to also check for the null obfuscation key

[maflcko]

@pstratem Why would someone write a null obfuscation key?

[pstratem]

@MarcoFalke it's a quirk of how the obfuscation code works, it's XOR so a null obfuscation key is the same as no obfuscation key

[sipa]

Do we ever write a null key? (as opposed to treating no key as null)

[maflcko]

@pstratem But it is never written to the db. This would be like saying I obfuscate every of my GitHub messages with the null obfuscation key. (It's redundant and not needed)

[pstratem]

@MarcoFalke I stand corrected

[laanwj]

Concept ACK but doubting if this or #6919 makes more sense.
Sure, backporting the whole thing involves somewhat more code but it seemed more useful than introducing a little bit less of code to just warn.

[maflcko]

@laanwj This can be cherry-picked to 0.10 without conflicts as well. As this issue seems popular ( #7258 (comment) ) we need either #7259 (this) or #6919, imo.

Keep in mind you can rebase #6919 simply on a commit which reverts #7259 (this), in case you want to reopen after #7259 (this) got merged. ("'Don't Let Perfect Be The Enemy Of Good'")

[laanwj]

Yeah, this is fine for 0.11. It's easier to test that it rejects a database than to test whether it works.

Would be nice to have at least one tested ACK, though.