fix: Reduce from error to warning for message when failing to terminate

[FrederikBolding]

When failing to terminate gracefully we currently log an error, it can be a warning instead since it doesn't prevent the Snap from terminating.

Intentionally also removing the logging of result which is almost always a symbol that clutters the error message.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.28%. Comparing base (4155700) to head (873e991).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3621   +/-   ##
=======================================
  Coverage   98.28%   98.28%           
=======================================
  Files         417      417           
  Lines       11772    11772           
  Branches     1832     1832           
=======================================
  Hits        11570    11570           
  Misses        202      202           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Gudahtt]

LGTM!

I had some questions about how we're handling this scenario, but regardless of the answers there, this seems like an appropriate change.

[Gudahtt]

Is this comment accurate? Does a failure to terminate gracefully always (or usually) indicate a bug in the snap? If so, what impact would we expect this to have on users if any?

I ask because we may want to consider forcibly disabling the snap and/or warning the user that it's misbehaving.

[FrederikBolding]

That was the assumption originally, but I removed it specifically because I didn't think it was accurate anymore.

The Snap gets very limited time to gracefully terminate (1s), so on lower-end systems it seems likelier now that we may see this as a "false-postive" of sorts. Especially since we see this on our own Snaps in production which shouldn't be hogging CPU by running a while-loop.

It may still warrant some investigation into whether we can better guarantee graceful termination and whether there is any issues in our own Snaps that cause this to happen more often.