Upgrade Watcher: Fix notification channel for crashes

[ycombinator]

What does this PR do?

This PR fixes a small bug where the incorrect log message was being emitted by the Upgrade Watcher if a crash was detected by it.

Why is it important?

For more accurate troubleshooting.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2023-02-24T16:21:23.001+0000

• Duration: 16 min 9 sec

Test stats 🧪

Test	Results
Failed	0
Passed	4919
Skipped	15
Total	4934

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages.

• run integration tests : Run the Elastic Agent Integration tests.

• run end-to-end tests : Generate the packages and run the E2E Tests.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	98.361% (60/61)	👍
Files	68.9% (144/209)	👍
Classes	68.08% (273/401)	👍
Methods	53.517% (837/1564)	👍
Lines	38.872% (9184/23626)	👍 0.034
Conditionals	100.0% (0/0)	💚

[cmacknz]

Thanks, also the reason we didn't catch is probably that viewing the upgrade watcher logs is exceptionally hard when analyzing previously failed upgrades #2262