Attach additional telemetry data to OTEL traces

[BryanFauble]

Problem:

1. We did not capture the size of the manifest (Bytes) or the version of schematic that produced the trace.
2. We did not capture the User ID on the trace.
3. We could not export logs out of schematic when running it as a regular server
4. I was encoding the environment into the service name

Solution:

1. Attach the package version to the resource which is applied to all of the traces
2. Attach the size of the manifest to the span that covers the download of the manifest
3. Attach the user ID to the trace
4. Move code out of conftest for sending logs next to the trace setup, allowing the configuration to work for both integration tests and the code when deployed as a server.
5. Update to use the DEPLOYMENT_ENVIRONMENT attribute to specify where the application is deployed instead of encoding this into the name of the service. This allows for filtering by service and environment separately.

Testing:

1. I verified the functionality of the exported trace data:
   

[thomasyu888]

Thanks for the quick PR here.

[thomasyu888]

Looks good to me so far! Thanks for adding all of this.

[sonarqubecloud]

Quality Gate passed

Issues
8 New issues
0 Accepted issues

Measures
0 Security Hotspots
57.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[thomasyu888]

🔥 LGTM! May want to add some documentation on how to export signoz traces and deploy signoz locally, but going to approve here.

[BryanFauble]

🔥 LGTM! May want to add some documentation on how to export signoz traces and deploy signoz locally, but going to approve here.

@thomasyu888 I've added instructions around this in this commit:

4de4b24

My thought is that I do not want folks to have to setup and run SigNoz locally - When I was testing it a while ago it takes a lot of system resources to run all of the components locally. What I wanted to do instead was to let people send their data into the dev instance of SigNoz. That is what the instructions I made above include.

My concerns with this approach:

1. Each developer will be given a unique client ID/client secret that they will use to export telemetry data. Off-boarding individuals was my concern here as this system is separate from something like Jumpcloud. It's an additional thing to be aware of as developers come and go.
2. We are given a quota of 1,000 access token that can be requested per month. If we use up all tokens for development, it might mean that schematic running in AWS cannot export it's telemetry data. This was the main reason why I am suggesting in the documentation that developers running locally manually create a token and use it, instead of the oauth2 client credential exchange that the deployed schematic server (Or github actions) would be using.