Add business metrics implementation guidelines

[S-Saranya1]

This PR adds guidelines for implementing business metrics in the AWS SDK for Java v2, based on team decisions.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[joviegas]

What about high level features which adds the User agent where the features are resolved before the context is built based on the Client settings? Should we also directly add it to the Execution Attribute ? (As in Transfer manager, Batch manager, CrossRegion etc)

[S-Saranya1]

Hmm yeah, good point to cover! Yes, if there are cases where high-level features are resolved before ExecutionContext is built and we can't access ExecutionAttributes directly.
We have two options: if we can somehow determine the feature from client configuration or execution parameters (like retry mode and protocol detection already do), then we can add it in AwsExecutionContextBuilder in core which avoids request mutation. But, if the feature requires analyzing specific request details that aren't available in client config, then request mutation is acceptable as a fallback ig. Will update the doc about it.

[joviegas]

Thanks for creating the guidelines this is very helpful.
Can you mention if there are any guidelines on changing an existing business metric , as in should it be considered backward incompatible or just bumping minor version is fine so that identifying the metrics with new version is easier.

[S-Saranya1]

Thanks for creating the guidelines this is very helpful. Can you mention if there are any guidelines on changing an existing business metric , as in should it be considered backward incompatible or just bumping minor version is fine so that identifying the metrics with new version is easier.

Changes to existing business metrics should be treated as backward compatible and only require a minor version bump I feel, what do you think? Since business metrics are purely observational, and don't affect SDK functionality or customer code behavior, customer applications remain unaffected, so changes like modifying an existing business metric are safe changes I feel. A minor version bump is sufficient and helps teams track when metric changes were introduced.

[joviegas]

only require a minor version bump I feel, what do

yeap minor version bump looks good