Return stats directly from restore function

[ashmrtn]

Rework restore return status so that later PRs will have a smaller diff

Instead of returning a status and then waiting on the message just return the restore stats directly. The status getter was only setup to wait for one item anyway and was setup to wait after the entire restore operation already completed (at end of
m365/restore.go:ConsumeRestoreCollections())

---

Does this PR need a docs update or release note?

• ✅ Yes, it's included
• 🕐 Yes, but in a later PR
• ⛔ No

Type of change

• 🌻 Feature
• 🐛 Bugfix
• 🗺️ Documentation
• 🤖 Supportability/Tests
• 💻 CI/Deployment
• 🧹 Tech Debt/Cleanup

Issue(s)

• too many service comparisons #4254

Test Plan

• 💪 Manual
• ⚡ Unit test
• 💚 E2E

[aviator-app]

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This PR was merged using Aviator.

---

See the real-time status of this PR on the Aviator webapp.

Use the Aviator Chrome Extension to see the status of your PR within GitHub.

[ryanfkeepers]

While I'm in favor of the pattern here, the intent is to replace this with the count.Bus anyway. What's your preference: keep this change and undo it later? Or drop it and we'll get around to it with the count.Bus update?

[ashmrtn]

Let's keep this for now as it makes switching to service-level handlers much simpler. We can rearrange/remove this after that point

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
1 Code Smell

No Coverage information
0.0% Duplication