SDK Feature Request

Describe the problem you’re trying to solve
Currently, the library defaults the service name to the Embrace library package name. This default behavior makes it difficult to distinguish between different applications. Without a clear, service.name, it becomes challenging to correlate telemetry with the correct application instance, leading to confusion in diagnostics and reporting.

Describe the ideal solution
The ideal solution is to use the appId as the service name when embrace.disableMappingFileUpload=true, while ignoring the minLength and maxLength constraints on app_id from embrace-config.json. This would ensure:

• Consistency: The service name accurately reflects the application's identifier, making it easier to distinguish between different applications.
• Clarity in Reporting: Teams can reliably correlate telemetry data with the correct application, improving diagnostics and operational insights.
• Future-Proofing: This approach lays the groundwork for potential future enhancements, such as allowing customers to explicitly define a custom app name or version.

The change aligns with the following discussion:

"Also, this is typically the name of the app. It's not something we capture is it? This is fine for now, but we might want to allow customers to specify an app name - or we default to the appId or something. Same thing for appVersion."
Originally posted by @bidetofevil in #375 (comment)

Describe alternatives you’ve considered or workarounds you’re using
We've explored the option of forking and making modifications, but this approach is error-prone due to the numerous interdependent components in the system. We also considered using addSessionProperty, but it may not provide the necessary consistency across telemetry data.

Additional context
Adopting this change will simplify the integration process for developers and ensure that the telemetry data being exported accurately reflects the intended application. This is particularly important for organizations using custom OpenTelemetry setups, where the clarity of service identification is crucial for operational monitoring and troubleshooting.

We greatly appreciate the team's ongoing efforts and contributions to the OpenTelemetry community. Thank you!

Checklist

• I have checked the SDK documentation to confirm this feature does not already exist
• I have searched open issues to ensure this feature has not already been requested
• I have included all necessary details to understand the SDK-specific use case