Orphan blocks are leaked on flush

[denravonska]

The blocks which are not yet a part of the chain are considered orphan and stored in mapOrphanBlocks which is periodically flushed during sync. The problem is that it's storing naked pointers which aren't deleted on flush which should cause a memory leak (haven't checked in Valgrind yet).

Change this to store a shared pointer until the block has been serialized to disk and detached from the orphan map.

[denravonska]

@tomasbrod @skcin I'm torn between the following fixes:

• shared_ptr: Correct and safe implementation but the change is larger and sticks out like a sore thumb compared to all the raw pointers in the system.
• raw ptr: Matches current implementation, small and isolated fix but still using unsafe raw pointers.

Thoughts?

[grctest]

but the change is larger and sticks out like a sore thumb compared to all the raw pointers in the system.

Would this introduce instability?

[denravonska]

@grctest I'd say no and that we want to move towards shared_ptr anyway, but implementing it in just one spot makes that particular spot not behave the way you have come to know or expect. For example:

void getValue1(string name, string& value)
void getValue2(string name, string& value)
void getValue3(string name, string& value)

Hypothetical refactoring of getValue3 into:

string getValue3(const string& name)

makes it correct but now it's inconsistent with the other two. It's pretty much the same here :)

I'm leaning towards making the small implementation now and doing a more broad switch to shared_ptr "in the future".

[tomasbrod]

This is still issue.

[pwnorbitals]

Submitted a pull request with a quick fix.
I'm just getting started with Github so I messed up with the first commit which included more than it should have. I think I successfully removed it.

[iFoggz]

#261

[pwnorbitals]

#609

[denravonska]

Fixed.