Experiment with destructors, use them to cleanup peerinfo leaks

[sinkingsugar]

This seems to fix the leaks,
I know destructors are controversial but they really get called on finalize and they seem to work.

Judge yourself here:

[arnetheduck]

I'd rather see a deterministic solution here - ie this is a bit of a trap in that the costs will show later

[sinkingsugar]

I'd rather see a deterministic solution here - ie this is a bit of a trap in that the costs will show later

I completely agree (set this PR as draft) but at same time the amount of issues to solve (which in turns generates more issues) increases.
This was a quick and dirty solution, that kept things simple. (my rationale)

[sinkingsugar]

been thinking a bit and well, using this solution for now might allow us to focus on other issues...
After all in .NET is regular practice:
https://docs.microsoft.com/en-us/dotnet/standard/garbage-collection/implementing-dispose#implement-the-dispose-pattern-for-a-derived-class
Of course it has to be a short term thing, but would lower the pressure on us for now.

[arnetheduck]

I see this as technical debt - the other work will be hampered by it - in .net, they added a construct in languages (using in C#) to make disposal deterministic, because it was causing so much trouble to have it done randomly. Better get to the bottom of the issue, just like getting to the bottom of result helped resolve a long-standing issue that was causing head-scratchers.

[zah]

There might be a way to get both determinism and immunity to programming errors. Instead of creating a destructor for the heap allocated object, consider making a non-ref wrapper object that holds a reference to the heap object and automatically closes it through a destructor defined for the wrapper. This is similar to spirit to smart pointer types, CHandle, etc.

Obviously, the feasibility of this depends on the way the PeerInfo values are shared between the different components. If you have wild sharing, then the policy needs to be either "the last reference is responsible for closing" (less deterministic) or "the PeerInfo should be safe to use in closed state".

[arnetheduck]

the peerinfo is quite wildly shared as it stands - ie it's half-way reused and half-way created on demand even if other peerinfos exist for the peer - ie the future in it is not useful really - #320 addresses some of it by simply removing the future and adding tracking events that can be used to implement this in client code.

[arnetheduck]

#320 merged, this is obsolete