I2C Error handling

[nefelim4ag]

As mentioned: #6674 (comment)
That would be nice to handle I2C errors, instead of the current shutdown approach.

There is a refactoring part to make things more obvious, where is the dev and where is the bus.

Errors handling works, but:

• Some MCUs do not clearly state what happens underneath.
• There should be a better way to define & pass errors to Klippy. I think it would be possible to reuse static_stings_id for that.
• When klippy inits and I2C returns an error, it is an unhandled exception, so it only appears in logs. There should be a fix actually to show it to frontends as before with shutdown msg.
• Missing handling for ldc1612 - used in homing sequence, there is no reason or way to handle errors.
• mpu9250 - used as an accelerometer, it looks safe to ignore anything, as with SPI sensors.
• Most sensors for now do something like:

def _sample():
        try:
            <code here>
        except Exception:
            logging.exception(...)
            self.temp = self.humidity = .0
            return self.reactor.NEVER

So, they stop updating data, if there is no heater for them, the machine will continue running.

---

About the code itself:

• Refactoring is done for clarity, it can be dropped or moved to separate PR.
  (I still somewhat think about non-blocking i2c, it feels right to store queue/buf at bus level),
• int ret looks a little dirty to me, maybe it is a bad approach here, I will be glad to receive any feedback.
  (maybe with timers there is a simple way with callbacks, cause we don't need to do something with stack).

Thanks.

[nefelim4ag]

I think this is more or less ready to gather feedback, so I will remove the "draft" label.
It feels stable, but it looks like initialization is now a little bit slower, because i2c write now is "synchronous".

[github-actions]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
   If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.