I got some feedback on #4377 and other places, I'm closing since this is not acceptable for bitcoind and people have already seen it. I will reopen it with new version still uses a class but without polymorphism.
Feedback is still welcomed.

It is not completely encapsulated because the attributes are public.
No polymorphism now. Less interesting for experimentation because there's no factory, but it should still be useful and in my opinion makes the POW code more clear.
For those who may want to see it, I left the polymorphic version here: https://github.com/jtimon/bitcoin/tree/old_proof

In general cleaning things up is pretty nice, and POW class seems to do that. Specific comments:

• some places seem to get less clean, not more:

-            if (GenerateProof(pblock, pindexPrev))
+            if (pblock->proof.GenerateProof(pblock, pindexPrev))

• The Hash(block header) code appears to be slower and more complex. Not the right direction for such a speed-sensitive area. That may be a problem for a cleanup we like but don't need...

Updated removing a bunch of unnecessary #include "pow.h"

Updated CBlockHeader::GetHash() with @sipa 's suggestion, which removes the extra complexity concern. I haven't measured the performance hit, but I expect it to be small.
@jgarzik I agree the call to GenerateProof is quite ugly, but nothing comes to mind to make it prettier...

CBlockIndex could gain a CheckWork() method that just calls proof.CheckWork(GetBlockHash()).

I created the CheckProof() method for CBlockHeader and CBlockIndex.
I could have also added GenerateProof to CBlockHeader or CBlock, but the ugly call is only on miner.cpp (which could disappear in the future, who knows) so I don't think it's worth it. It doesn't feel like it belongs to a core library since it is only for the miner (which is only used for testing).

Commits reordered so that the PR is easier to read (by creating the Proof class early on and then slowly encapsulating things).
I left the proof generation part (mining) for later, so GetChallengeUint() method is needed for now SetSolutionUint() is also used in miner.cpp, but that was already used miner_tests.cpp.

I have left the last two commits with multiple small changes for later, after I know what's the most acceptable way to encapsulate the pow around miner. I will continue that discussion in #4423. But the "final touches" will depend on that, so there's no reason to include them before or stop this PR until that is resolved. Also the last commit was quite noisy.

mhmm, I wonder if nBits and nNonce should be uint32_t instead of unsigned int...

Yes, I believe all integers being serialized anywhere should eventually be turned into (u)intN_t's, but let's do that separately. There may already have been some PR for (part of) that.

It needed rebase because #4180 was merged so I just changed unsigned int to unit32_t too.

Rebased

I like the changes, I did have a thought that maybe CProof is at slight risk of ambiguity (E.g. SPV proof vs block proof).

I think CProof should be split in its core data structure (which can go in core, or be included by it), and validation functions that take a CProof and perform the various checks on them (which can be in server). Not doing that will for example result in libscript contain block PoW validation...

Having the class in core with only the serialization and using it with the functions is incompatible with making the fields private/protected, which is the final goal of this series of PRs.
After thinking about this a lot there's doesn't seem to be any solution compatible with both goals that isn't ugly one way or another.
I guess I should just keep moving functions here first and leave the class for later when we have a solution that doesn't make anyone unhappy.

"Not doing that will for example result in libscript contain block PoW validation"
Not necessarily, only if you want to put Transaction and BlockHeader in the same module, script doesn't need BlockHeader's at all.
There could be a xxx.o with only COutPoint, CTxIn, CTxOut and CTransaction, which is everything script/interpreter needs.

I'm fine with splitting core into a transaction and a block part, and that would indeed suffice for now, but it would still mean that anything that uses block headers will depend on its validation code to. I don't like it, but I can't immediately come up with an example of something that would use headers parsing, but not need the ability to verify proofs.

I reduced the scope of the PR again.
Now it only creates a minimal CProof class independent from pow.o.
It's built on top of #5100 and #4793.

Rebased on top of the latest #5100 and without depending on #4793 (if that get merged first I can update this with the older version).

Rebased to make it more readable.

Closing in favor of #5171, without a class.