fix: use unique_ptr for geometry in DD4hep_service, hand out not_null const pointers

[wdconinc]

Briefly, what does this PR introduce?

While looking into #1032, #1035, #1036 I started realizing two things:

• cell ID position converters are created by algorithms from geometry instead of doing this once in the service,
• there is no const protection in the detector pointers passed to algorithms (i.e. an algorithm could change geometry),
• there is no protection against null pointers being passed from geometry.

The first two points are related since the interface for creating a cell ID position converter requires a non-const detector (see also AIDASoft/DD4hep#1148).

This PR centralizes the creation of cell ID position converters, clarifies ownership through unique_ptrs, and makes sure no null pointers are passed to the algorithms. In places where the constructor gets the const not_null pointer, we can also impose this in the class on the relevant member variable.

What kind of change does this PR introduce?

• Bug fix (issue: avoid creation of cell ID position converters in algorithms)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators:
  • @simonge reordered MatrixTransferStatic init arguments
  • @c-dilks @chchatte92 this also affects RichGeo_service etc.

Does this PR introduce breaking changes? What changes might users need to make to their code?

Yes, now requires GSL (which has always been in eic-shell and is a requirement).

Does this PR change default behavior?

No.

[veprbl]

Do we really want to smear non-null check across our interfaces? Is it not enough to just ensure that the geometry service doesn't return null.

[wdconinc]

Do we really want to smear non-null check across our interfaces? Is it not enough to just ensure that the geometry service doesn't return null.

It's heavy on notation, I admit, but the requirement for a not_null pointer is in this case imposed by the algorithms, not by the service. The DD4hep_service can satisfy the demand by promising to return a not_null pointer. Putting the requirement in the algorithms makes clear to anyone working in those algorithms that detector can be relied upon to be not_null (yeah, this benefit it kinda negated by the whole init-function and clearer in the RichGeo_service).

[wdconinc]

@veprbl I removed the gsl::not_null on all algorithms init calls in b9b97f4

This doesn't really add much utility on the init calls if we can't set it on the class members. I've kept it in DD4hepBfield since there we construct with the detector geometry provided as constructor argument (similar to RichGeo_services).

[c-dilks]

The dRICH benchmarks look okay with this PR.

[veprbl]

@veprbl I removed the gsl::not_null on all algorithms init calls in b9b97f4

This doesn't really add much utility on the init calls if we can't set it on the class members. I've kept it in DD4hepBfield since there we construct with the detector geometry provided as constructor argument (similar to RichGeo_services).

Yes. That was my point, that it's probably the return values where gsl::not_null makes sense (I don't claim any deep philosophical understanding of GSL, though).

[veprbl]

Diff LGTM, capybara happy