feat: config for custom batch span processor

[tim-mwangi]

Description

We need to be able to pick whether we use out customer bsp https://github.com/hypertrace/goagent/tree/main/instrumentation/opentelemetry/batchspanprocessor or use the stock one in the opentelemetry go repo.

Testing

Unit and local tests

Checklist:

• [✅ ] My changes generate no new warnings
• [✅ ] Any dependent changes have been merged and published in downstream modules

[codecov]

Codecov Report

Attention: Patch coverage is 87.50000% with 2 lines in your changes are missing coverage. Please review.

Project coverage is 58.37%. Comparing base (eab5d40) to head (d4e5aa2).

Files	Patch %	Lines
instrumentation/opentelemetry/init.go	85.71%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #229      +/-   ##
==========================================
+ Coverage   57.80%   58.37%   +0.57%     
==========================================
  Files          69       69              
  Lines        2737     2746       +9     
==========================================
+ Hits         1582     1603      +21     
+ Misses       1085     1074      -11     
+ Partials       70       69       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tim-mwangi]

Oh I missed some places eg. RegisterServiceWithSpanProcessorWrapper(). Will fix.

[puneet-traceable]

Just to understand this more, why was this conditional to run BatchSpanProcesor until now? What I am trying to understand is what would happen if customBsp is false and metrics are enabled? Will non-modified batchSpanProcessor work?

[tim-mwangi]

The only reason for the custom BatchSpanProcessor(BSP) is to be able to collect span metrics - received, dropped and unsampled - as they hit the exporter. So if metrics is disabled, there's no need for it.
As if this PR if custom BSP is false and metrics are enabled, we use the stock BSP. I think this behavior will remain even in the recover from panic PR. And I'm thinking I will remove the metrics enabled requirement in that PR so that we can recover even if metrics are disabled and panic happens when exporting the traces.