Set all azcosmos telemetry spans to have the Kind of SpanKindClient

[kjg]

Many tracing tools use the kind of the telemetry span to show the span in a specific way. By setting the azcosmos spans to type of Client, they will allow telemetry tools to treat the spans as the span of a database Client. When a span kind is not specified it is default to a kind of "Internal" which shows up to tracing tools as if these spans are part of internal code logic instead of spans generated by database client.

I've bumped azcore to v1.16.0, because that's the first version of azcore that allows the Span kind to be specified in the StartSpanOptions.

• The purpose of this PR is explained in this or a referenced issue.
• The PR does not update generated files.
  • These files are managed by the codegen framework at Azure/autorest.go.
• Tests are included and/or updated for code changes.
• Updates to module CHANGELOG.md are included.
• MIT license headers are included in each file.

[github-actions]

Thank you for your contribution @kjg! We will review the pull request and get back to you soon.

[kjg]

The lint errors on this PR appear to be unrelated to the changes, should I take any action on them?

[Pilchie]

@simorenoh @analogrelay - can one of you take a look at this.

[analogrelay]

The lint errors on this PR appear to be unrelated to the changes, should I take any action on them?

I believe you're correct, they're unrelated, but I'd love to get us green on this PR before we land it. Let me take a look and see if it's a straightforward fix. If it is, it'd be good to get it in here.

[analogrelay]

Yeah, it's a straightforward fix, just removing the nil checks here:

cosmos_item_request_options.go:45:5: S1009: should omit nil check; len() for []string is defined as zero (gosimple)
	if options.PreTriggers != nil && len(options.PreTriggers) > 0 {
	   ^
cosmos_item_request_options.go:49:5: S1009: should omit nil check; len() for []string is defined as zero (gosimple)
	if options.PostTriggers != nil && len(options.PostTriggers) > 0 {
	   ^
cosmos_location_cache_test.go:186:5: S1009: should omit nil check; len() for []github.com/Azure/azure-sdk-for-go/sdk/data/azcosmos.accountRegion is defined as zero (gosimple)
	if dbAcct.WriteRegions == nil || len(dbAcct.WriteRegions) == 0 {

I haven't yet been able to track down why these weren't failing before. There was a change to this file last month that built successfully, and as far as I can tell, we haven't changed our golangci-lint config since then. I'll do a little looking, but the fix should be safe and straightforward. len(nil) is safe to call and returns 0, which works for all these cases. @kjg would you mind making that change here to get us green? I'm also happy to add it to your PR if the permissions are set up for that, or make the change in a separate PR to main that we land first, whatever works for you. We don't need this check to merge but I don't like merging with red checks unless there's a very good reason to :).

[kjg]

I'll make it here, Thanks!

[analogrelay]

Looks good to me. I'd like the previously-failing lint check to pass before merging (though it's not directly related to the main PR).

[analogrelay]

I haven't yet been able to track down why these weren't failing before.

Looks like there was an update of our golangci version in #23536 that was green in the PR (because that PR didn't build all the packages) but failed in main because of the linter update. That likely explains why the lint started failing without a specific PR to cause it.

[kjg]

It looks like all the tests are passing now, so I think this is good to go. Thanks for the guidance!

[analogrelay]

@kirankumarkolli @Pilchie @simorenoh @kushagraThapar , I'm not a CODEOWNER yet. Could one of you take a look at this?