Replace `serviceInstanceDetector` with `serviceDetector`

[MikeGoldsmith]

I like the idea of a serviceDetector that handles everything service related, meaning instance ID and name, and making it clear the priority of where the value comes from, so it's worth opening a new issue/PR to handle that.

To answer your other question:

OTEL_SERVICE_NAME is handled by service or by env

I think being handled by the service would make more obvious to users, because is in the name, and we can make the priority clear of where the value comes from.
Using a serviceDetector would also help with the decision between the random uuid and defined service instance ID, where today depending on the order the users adds (serviceInstanceId, env VS env, serviceInstanceId) it returns different results.
That would be a breaking change, so as long as we make that clear to users, then should be fine

Originally posted by @maryliag in #6435 (comment)

[MikeGoldsmith]

@maryliag Please can you add this to the declarative config board?

[maryliag]

done! thank you for opening!

[trentm]

Thinking out loud:

• For service.name, OTEL_SERVICE_NAME=foo should win over OTEL_RESOURCE_ATTRIBUTES=service.name=bar. This means we'd want the service detector to come after the env detector, at least while Resource handling is order dependent.
• For service.instance.id, if there is a value in OTEL_RESOURCE_ATTRIBUTES for it, then that should win. This means we'd want the env detector to come after the service detector.

Those two config on the ordering of service and env. I'm not sure how to resolve that.

---

Also, note that https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-detector-name doesn't list an "env" detector. I'm a little confused how things should work here with declarative config. Perhaps there should NOT be a detector named "env"? Instead a user would be expected to have this in their config.yaml:

resource:
  # SNIPPET_START
  attributes:
    - name: service.name
      value: foo
    - name: service.instance.id
      value: bar

Or:

resource:
  attributes_list: "service.name=foo,service.instance.id=bar"

Or if they want to use OTEL_RESOURCE_ATTRIBUTES then:

resource:
  attributes_list: $(env.OTEL_RESOURCE_ATTRIBUTES)

(or whatever the envvar syntax is for declarative config yaml files).

?