Add deployment type #2334

[thompson-tomo]

Progresses #2334

Changes

Records the type of deployment occuring so that provisioning of a new instance running the software can be differentiated from adding the files to a store.

Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[joaopgrassi]

I'm having a hard time finding the difference between these two. Could you elaborate more? I'm also having a hard time finding how this attribute would be useful/used in reality. Can you maybe add use-case for it, or any instrumentation already using it?

[thompson-tomo]

A scenario is within your cicd pipeline you could publish your artifact's to a registry/store for instance docker hub if building a container or could be provisioning a container instance running the artifact's.

[lmolkova]

I don't believe there is industry-wide notion of deployment type that is also known and available inside ci/cd pipeline. It's not clear how existing tooling would populate this attribute. The type is also a very broad term that could mean a lot of things, including k8s deployment strategy or similar Azure DevOps thing.

Defining semantic conventions usually means researching how things are done in multiple environments, finding commonalities, ensuring information is available and then documenting how to capture new things in these different environments.

Currently it seems we're inventing something new that is not widely applicable. It goes against best practices documented in this repo

semantic-conventions/docs/how-to-write-conventions/README.md

Lines 127 to 129 in 846028d

	- When defining a broad attribute applicable across multiple domains or systems,
	check for existing standards or widely accepted best practices in the industry.
	Avoid creating generic attributes that are not based on established standards.

[lmolkova]

See #2674 (review) for the reasoning