fix(observability): do not hold span guards across await points

[gwenaskell]

Summary

In the topology builder, the components builder functions enter a tracing span, which carries the tags that will automatically be injected into the metrics registered at build time below. This entered span guard is held while calling the inner source build function, which is asynchronous. Holding an entered span across an await point is strongly discouraged in tracing docs: if the awaited future is non-trivial and actually yields to the tokio runtime, the entered span guard is leaked on the current thread's stack and lost if the task is later resumed on a different thread.

What this means concretely: any source, transform or sink which build method actually performs async work that pauses it temporarily will very likely loose all component tags on the metrics registered at build time within that source / sink after the await point.
This includes (the list may not be exhaustive):

• all sinks configured with a disk buffer (which often yields during initialization due to IO work)
• sources/transforms/sinks like gcp_pubsub and microsoft_sentinel, which perform IO work for authentication at build time

Vector configuration

Our E2E tests flagged missing metrics for gcp_pubsub, microsoft_sentinel, and sinks using disk buffers. utilization was frequently not reported.

How did you test this PR?

Change Type

• Bug fix
• New feature
• Dependencies
• Non-functional (chore, refactoring, docs)
• Performance

Is this a breaking change?

• Yes
• No

Does this PR include user facing changes?

• Yes. Please add a changelog fragment based on our guidelines.
• No. A maintainer will apply the no-changelog label to this PR.

References

Notes

• Please read our Vector contributor resources.
• Do not hesitate to use @vectordotdev/vector to reach out to us regarding this PR.
• Some CI checks run only after we manually approve them.
  • We recommend adding a pre-push hook, please see this template.
  • Alternatively, we recommend running the following locally before pushing to the remote branch:
    • make fmt
    • make check-clippy (if there are failures it's possible some of them can be fixed with make clippy-fix)
    • make test
• After a review is requested, please avoid force pushes to help us review incrementally.
  • Feel free to push as many commits as you want. They will be squashed into one before merging.
  • For example, you can run git merge origin master and git push.
• If this PR introduces changes Vector dependencies (modifies Cargo.lock), please
  run make build-licenses to regenerate the license inventory and commit the changes (if any). More details on the dd-rust-license-tool.

[bruceg]

Makes sense to me, and has a side benefit of reducing the complexity of those long topology builder functions.