fix: Replace long running span with short lived spans

[NickLarsenNZ]

Description

Before, the span lived as long as the app ran which is discouraged for (subjectively) long-running apps. This change moves the span to inside the loop, and move existing init stuff into a separate span (so that output is still distinguishable).

Also replace stackable_operator::utils::print_startup_string with tracing::info! to get the correct call-site displayed.

Why are long spans discouraged?

Two problems arise when troubleshooting an application via tracing:

1. Long spans just have too much detail to sift through. The parent span (which is basically the trace) ends up with too much detail. It should be scoped down to useful "start" and "stop" points, eg:

• The app starting up, and
• Each iteration of the loop (there is not much value in covering the time in between runs).

2. Large traces will get rejected by having too many child spans, or just too much data (depending on the receivers configuration).

Definition of Done Checklist

• Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant
• Please make sure all these things are done and tick the boxes

Author

• Changes are OpenShift compatible
• Integration tests passed (for non trivial changes)

Reviewer

• Code contains useful comments
• (Integration-)Test cases added
• Documentation added or updated
• Changelog updated
• Cargo.toml only contains references to git tags (not specific commits or branches)

Acceptance

• Feature Tracker has been updated
• Proper release label has been added