Create a plugin-specific development guide

[dyladan]

• [x] This only affects the JavaScript OpenTelemetry library

This is separate from the contributing guidelines which are made for newcomers and are fairly unspecific.

Somewhere we need to document all the small things that plugin developers need to know, and possibly have a checklist that every plugin PR should go through. Something like the following:

• Only uses public tracer api. this is important because we can't guarantee our tracer will be the one used.
• Plugin covers the whole documented public API surface of the instrumented library. If not, list the known uncovered cases and explain why.
• Tests verify that spans created have correct parent
• Behavior of user's application is unchanged
  • this includes incorrect use of the API. If the user sends incorrect arguments to a function, we need to make sure to send the same incorrect arguments
  • this includes error handling. if the library throws an error, we need to make sure to re-throw it unchanged
• the plugin cannot throw an error (within reason)
• the plugin does not leak memory
  • this includes if the user uses an api incorrectly.
  • one example is the xhr plugin which stores in-flight spans. They are created when open is called and ended when send finishes. If the user never calls send and drops their reference to the xhr object, we have to make sure we don't keep a reference or we will leak memory.

I'm sure there are others, this is just what I thought of

[mhennoch]

We have https://github.com/open-telemetry/opentelemetry-js/blob/main/doc/instrumentation-guide.md Can we close this @dyladan?

[dyladan]

Hmm I originally thought yes we could close it, but the linked docs show how to use the instrumentation package to write an instrumentation. We still need to document what our requirements are to accept them into the contrib repo.