Brett McBride

@open-telemetry/php-approvers @Nevay I think this is ready for review: NB that it targets 2.x branch and has some BC breakage, which I've started to document in `docs/upgrading.md`

@open-telemetry/php-approvers this is ready for another review. I think all feedback from Nevay addressed and OK'd.

@cedricziel I hope you don't mind, I've ported these detectors over to contrib in https://github.com/open-telemetry/opentelemetry-php-contrib/pull/444 I've also merged the change to move service.instance.id into its own (non-default) detector to try...

@GrzegorzDrozd I've finally had some time to look at metrics generation. I started down the path of tracking everything in pre and post hooks, in #396 - when I got...

> But that would force someone to use spans with metrics? What if they want only to use metrics? What about sampling? So with this argument I think I should...

> do we want to add metrics to existing span processing or create separate files to allow developers to chose if they want to use metrics, spans or metrics +...

I think the spec authors intended it to be done via with [TracerConfig](https://github.com/open-telemetry/opentelemetry-php/blob/main/tests/Integration/SDK/Trace/TracerConfigTest.php) - it's been part of our SDK for a while, but not implemented in any instrumentation modules....

> Not sure to understand. You prefer having a trcer for each client and each middleware ? I'm only speaking generally, because I don't know symfony deeply and didn't write...

I think this issue is still live in 3.4.3...maybe we should skip that test for `3.4.x`, or permanently with a todo + tracking issue?

Not tested yet, but it sounds like we're good from [3.4.5](https://github.com/xdebug/xdebug/releases/tag/3.4.5)