Azcosmos no tracer to pager

[kjg]

• Refs Provide a way to customize the span created by Pager[T].NextPage #23294

Originally the thought was that the azcore Pager should provide a way to better customize the spans it creates, and that the azcosmos Pager based spans could take advantage of that.

As I was digging it to try to make that work I did realize a few things.

1. The spans being set within the azcosmos Fetcher functions are currently being surpressed due to the StartSpan code policy to not allow nested spans most of the time.
2. Adding a way to customize the span creation in the azcore Pager would add complexity for what is currently just a simple wrapper around the Fetcher function
3. If a Tracer is not set on the PagingHandler a null Tracer is used which results in StartSpan not adding an active span to the context.

Considering all the above. I think the simplest way to allow azcosmos to customize the tracer used for Pager spans is to not set a tracer in PagingHandler, and allow the custom one within the Fetcher function to take precedence.

For testing, I've pushed a commit with just the tests to show that before this change the tests fail to have the query_ spans. Then I've pushed the commit that removes setting the Tracer and you can see the tests all pass now.

Example of a failing test:

• 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]

Adding tests now.

[analogrelay]

LGTM

[kjg]

@analogrelay Is there anything else that needs to be done before this can be merged?

[analogrelay]

Nope, this is good to go. Thanks for the ping!