[wip] Introduce MaybeSharedPtr type and use it for mutable objects

[tmadlener]

BEGINRELEASENOTES

• Introduce MaybeSharedPtr<T> for usage in the mutable user facing classes via MaybeSharedPtr<Obj>.
  • Allows for a cleaner hand-off of the ownership from a "temporary" object that is added to a collection without introducing the heap-use-after-free problems in heap-use-after-free in ExampleCluster #174.
• Make the Obj* in Const classes unmanaged.
• Make the clone function always return mutable objects (keeping the same relations as the original)
• Fixes memory leak in SIOReader for collections that have not been requested by the user.
• Remove ObjBase and move the ObjectID into the Obj classes.
• Add possibility to build podio with different sanitizers via a cmake flag.
  • Add github actions workflow file for some of the sanitizer builds

ENDRELEASENOTES

Fixes #174

The MaybeSharedPtr holds the managed pointer as well as a simple control block which manages its own lifetime and potentially that of the managed pointer. Ownership of the managed pointer can only move from the MaybeSharedPtr to something else, but never the other way around (unless it has been initialized with an unmanaged pointer). This construct allows to avoid the issues in observed in #174, because the control block that decides how things should be destructed will still be around even if the managed pointer is already gone. Previously the managed pointer and the control block were one entity so this could not be guaranteed.

In order to avoid too much overhead it is only used in the mutable objects but not in the immutable ones; The size of the mutable user objects doubles, since it now has two pointers instead of just one, while the one of the immutable ones remains the same.

Another important difference: The immutable objects no longer manage their Obj* and always assume that someone else does this for them. This should not really be a problem as in most of the cases it will be the collection that owns the Obj*. However, it could introduce some subtle lifetime issues, that could occur when a mutable object is implicitly converted to an immutable one, e.g.

std::vector<ConstMCParticle> mcParticles;
{ // scope to illustrate the problem
  auto mcP = MCParticle();
  mcParticles.push_back(mcP);
}
// this will create a "dangling reference" that internally uses an already destroyed Obj*
auto mc = mcParticles[0];

Making the Const objects also use the MaybeSharedPtr could be done from a technical point of view, however, that leads to a problem with cyclic dependencies, e.g. here:

podio/tests/unittest.cpp

Lines 112 to 126 in ed207e8

	TEST_CASE("Cyclic"){
	auto start = ExampleForCyclicDependency1();
	auto isAvailable = start.ref().isAvailable();
	REQUIRE_FALSE(isAvailable);
	auto end = ExampleForCyclicDependency2();
	start.ref(end);
	isAvailable = start.ref().isAvailable();
	REQUIRE(isAvailable);
	end.ref(start);
	REQUIRE(start == end.ref());
	auto end_eq = start.ref();
	auto start_eq = end_eq.ref();
	REQUIRE(start == start_eq);
	REQUIRE(start == start.ref().ref());
	}

Here something an additional "weak count" (a la std::shared_ptr + std::weak_ptr) would be necessary to break the cycle and ensure proper cleanup, otherwise the two references above keep each other alive indefinitely.

In the end, the lifetime issues around the Const objects could be acceptable, if properly documented. Otherwise we might have to find a more sophisticated approach than the one proposed here.

[tmadlener]

Looks like builds that involve any sanitizer are not really happy with root.

[andresailer]

Suggested change

	/// collection, name, and flag to indictate whether it has been requested by
	/// collection, name, and flag to indicate whether it has been requested by

[tmadlener]

Superseded by #514