Fix memory leak with ResetKernel

[hakonsbm]

Nodes are created with new in GenericModel:

nest-simulator/nestkernel/genericmodel.h

Lines 154 to 158 in d7ef15b

	GenericModel< ElementT >::create_()
	{
	Node* n = new ElementT( proto_ );
	return n;
	}

Then the node pointers are stored in memory_ in Model. However the nodes are never deleted, which leads to a memory leak when calling ResetKernel. With only a few thousand nodes, calling ResetKernel multiple times can add up to hundreds of MB of leaked memory.

This PR puts Node pointers in smart pointers within memory_, so that the Nodes are automatically deleted when the model is destroyed. The explicit call to the node destructor in NodeManager is removed because it interferes with the deletion of the nodes at the end of Models lifetime. This fixes #2519. @ChenK19 Can you check if #2512 is fixed by this as well?

[nicolossus]

LGTM!

[heplesser]

Is there any performance effect of replacing a normal with a smart pointer?

[hakonsbm]

@heplesser Create with this branch appears to be initially slightly slower (~4 % for 1e6 nodes), but faster after the first ResetKernel (~55 % s for 1e6 nodes).

[heplesser]

@heplesser Create with this branch appears to be initially slightly slower (~4 % for 1e6 nodes), but faster after the first ResetKernel (~55 % s for 1e6 nodes).

Are there any effects on simulation time? I assume that smart pointers take more memory (reference counting needs to happen somewhere) and thus worry that they are cached less effectively, so that neuron access during spike delivery might become less efficient. And since neurons are created in a single place and deleted in a single place, I don't think we really need smart pointers.

I think in #2316 we just overlooked the need for destruction when we went away from the memory pool. In the longer run, we should keep this comment by @jougs in mind.

[heplesser]

I think we can solve this without smart pointers and the performance and memory cost they imply.

[heplesser]

I just did a little test, comparing a program filling a vector with 2^10 *int vs std::shared_ptr<int>, using g++12 and clang++14. In both cases, the shared pointer takes very close to 40B extra memory per vector element compared to a plain pointer.

For more on the implementation in the gcc case, see https://gcc.gnu.org/onlinedocs/libstdc++/manual/memory.html#std.util.memory.shared_ptr.