Should auto-instrumentation be a top level concern?

[lzchen]

The OpenTelemetry Python SDK currently provides the ability for users to auto-instrument their code. While auto-instrumentation itself has not been spec'd out explicitly, other languages have implemented their own mechanisms for auto-instrumenting code. Java even has a dedicated product and repository solely for instrumenting with OpenTelemetry without any code.

Our current approach to auto-instrumentation in terms of support and feature set is: "implement this feature for manual instrumentation and hope that it works for auto-instrumentation". We then retroactively fix bugs that come up. As OpenTelemetry Python is becoming more mature, and it is become more evident that auto instrumentation is a very used/desired feature, we should probably treat it as a top-level product/offering rather than a feature. This will mean some additions in our development process, including:

1. Writing test suites to test all changes to see if they work when auto-instrumented
2. Documenting a comprehensive list of capabilities/short-comings of auto-instrumenting an application (users should know what they get when manual instrumenting vs auto instrumenting) + adding more examples of auto-instrumentation being used (rather than just the collector) with configuration options
3. Prioritizing features/issues related to auto-instrumentation

This will hopefully reduce the amount of issues and questions related to auto-instrumentation, as well as make our auto-instrumentation product more robust and less error-prone. Given our limited resourcing, I suggest we take these tasks one step at a time and iteratively change our codebase to reflect the rising importance of auto-instrumentation (we can maybe start with documentation). I'm also wondering how we would want to include testing for auto-instrumentation (do unit tests even make sense/add any value?)

Thoughts? @aabmass @srikanthccv @ocelotl @owais @jeremydvoss

[ocelotl]

Suggest that we convert this issue into a discussion, I prefer to keep issues for things that can be closed with a specific PR.