MOVEONLY-ISH: allocators: split allocators and pagelocker

[theuni]

Part of a larger effort to clean up dependencies, this is a straightforward change. Headers were fixed up as necessary, and I added the bitcoin-config.h include in pagelocker.cpp in case it was picked up from elsewhere before.

Pagelocker is only used for sensitive info, so don't require it for things that just want zero-after-free. In particular, this un-tethers streams from boost and global app-state.

[paveljanik]

utACK, I like this style of cleanup.

[theuni]

nits addressed.

[jtimon]

ut ACK

[laanwj]

Agree on the idea, although I'm wondering whether src/allocators should be a first-class directory or this stuff should be in the more general src/support.

[theuni]

@laanwj To clarify, what do you intend src/support to house?

Either way, I'm happy to move it if you'd prefer it there.

[jtimon]

Maybe we can move some utils there or maybe we will find out what else to move there later. Just thinking out loud...

[laanwj]

@theuni Let me try: src/support is for OS support that means lower-level utility functions that depend on calls to the OS, with potential side effects.

• Currently cleanse is in there, which makes sense.
• Allocators also fall squarely into that category (also isn't cleanse mostly/only used by the allocators?).
• Low-level synchronization primitives would also fit here.
• Pure utility functions (e.g. utilstrencodings) would not belong there. They are OS-independent and should even work in a completely static computational environment like moxiebox.

This is analogous to leveldb's port_* and env_*. There is a slight overlap with compat, although compat deals with (pure) functions that lack from a certain C/C++ library but are part of some standard.

Maybe we should write a plan how we like the tree organized so that these things are more clear. Maybe there are good arguments why allocators makes sense as a category/library of itself, I just think that the default should be to try to fit something into a broad category and not create too many subdirs of src/.

[theuni]

@laanwj Ok, that sounds good. To me, 'support' implied that the functionality within would be provided by 3rd party libs. Your description makes sense and I follow now, thanks.

If there were more allocators, or more planned, I'd argue that they make sense by themselves. But 2 really isn't enough to justify that.

I'll move and rename to fit.

[theuni]

Moved to support.

[jtimon]

re-utACK

[sipa]

utACK

[jgarzik]

ut ACK

[sipa]

Needs rebase.

[laanwj]

Merged via d7d187e (only conflict was a #include in the tests)