fix: keep waiting after unexpected RTU slave response

[MrAlaskan]

Summary

Fix RTU confirmation handling to ensure that replies from unexpected slaves do not prematurely abort in-flight requests. See issue #861.

According to the Modbus Serial Line Protocol and Implementation Guide V1.02, if a master receives a frame from an unexpected slave while waiting for a response, it should discard the frame, keep the response timeout running, and remain in the "Waiting for reply" state.

Root Cause

The previous implementation handled unexpected slave replies inconsistently, violating the RTU master state machine:

• The RTU confirmation pre-check treated slave address mismatches as an EMBBADSLAVE error.
• The client confirmation path propagated that error immediately and aborted the transaction.
• On a shared RS485 bus, replies from non-target slaves or delayed frames from earlier exchanges may legitimately appear while the master is still waiting for the expected response.
• Aborting the entire transaction on a mismatched slave address prevents the master from receiving the valid reply from the requested slave if it arrives shortly afterward.

Fix

Introduced a dedicated receive_confirmation() retry loop for RTU clients.

Instead of aborting immediately when an EMBBADSLAVE condition is detected, the client now:

• Discards the unexpected frame
• Preserves the original response_timeout
• Recomputes the remaining wait time after each ignored frame
• Continues waiting until the expected reply is received or the original timeout expires with ETIMEDOUT

This aligns RTU confirmation handling with the Modbus RTU specification and avoids prematurely terminating valid in-flight requests.

[cla-bot]

We require contributors to sign our Contributor License Agreement. In order for us to review and merge your code, please fill https://forms.gle/5635zjphDo5JEJQSA to get added. Your document will be manually checked by the maintainer. Be patient...