Defining instrumentation modules publishing coordinates format

[LikeTheSalad]

We currently have a logic that does the following iirc: io.opentelemetry.android:instrumentation-[project-name] that's the case for all instrumentations except for the okhttp one which is: io.opentelemetry.android:okhttp-3.0-library and also recently with the httpurlconnection one as well. This happens because the okhttp/httpurlconnection modules are inside 2 levels of dirs within the instrumentation one, as opposed to just one as every other instrumentation, and since the logic we have just takes the first parent dir of a module and prepends its name into the artifact id, we don't get instrumentation- as part of the artifact-id, but okhttp-3.0- and httpurlconnection- respectively instead.

I think we should try to standardize these URIs across all instrumentations, and the options I'm thinking about could be the following:

• io.opentelemetry.android:instrumentation-[module-name]
• io.opentelemetry.android.instrumentation:[module-name]

Now, the usage of module-name in the artifact-id becomes a bit tricky with instrumentations that do bytecode weaving as they need more submodules, their structure looks like the following:

instrumentation/
├─ target-lib/
│  ├─ agent/
│  ├─ library/
│  ├─ testing/

So for example, if we just used module-name in the coordinates for the example above, we wouldn't include the target-lib name and, considering that we wanted to use the following format: io.opentelemetry.android.instrumentation:[module-name] for the purposes of this example, the coordinates that we would get for this lib's modules would be the following:

• io.opentelemetry.android.instrumentation:agent
• io.opentelemetry.android.instrumentation:library

Which can easily clash with another instrumentation that has the same subproject structure. So based on the above, part of the decision of what format to use should also take into account what to do for these cases.

To summarise, I'd like to define the following:

• What's the URI format we should use for instrumentations.
• What to do about instrumentations that need to publish multiple modules, such as the ones that do bytecode weaving.