feat: add remote modbus rtu driver support, refactor ModbusRTUDriver to use SerialPort directly

[flxzt]

Description

This PR adds support for using Modbus RTU serial ports remotely. It does that by removing the ModbusRTU resource, and let the driver use SerialPort and NetworkSerialPort resources directly.

In order to archieve this, I moved the fields timeout and address into the driver.

My reasoning is that it makes more sense to let the resource manage the entire bus, and let the driver only control one slave (= address). Same for the timeout, this can be slave-specific.

It seems to be working fine remotely with a Waveshare RTU relay, so far I only tested it with a low baudrate 9600 so I don't know how well the remote serial connection behaves with higher rates.

as mentioned in #1370 I am unsure if it is "okay" to replace the ModbusRTU resource, because this is obviously a breaking change.
Adding a exported NetworkModbusRTU resource would be the alternative, but it would mean a lot of repetition with NetworkSerialPort. But I might have missed intentional architectural decisions here, so I can implement whatever makes the most sense!

Once this is resolved/merged, I'll follow up with an added WaveshareRTURelay driver

Checklist

• Documentation for the feature
• Tests for the feature
• The arguments and description in doc/configuration.rst have been updated
• PR has been tested

[jluebbe]

Looking at the minimalmodbus documentation, it seems to support communicating with multiple instruments on the same bus by sharing a pyserial object, but with the ModbusRTUDriver we can bind only one device to the serial port resource.

Wouldn't it make more sense to have drivers for each instrument bind to the SerialDriver and pass the SerialDriver.serial attribute to the minimalmodbus Instrument constructor?

To allow multiple client drivers binding to a SerialDriver instance, you'd need to override the resolve_conflicts method from the ConsoleExpectMixin and allow multiple active clients only if they are all instrument drivers (and then call super()).

Going this route would also avoid the backwards compat problem, as the new driver would be a ModbusRTUInstrumentDriver.

[jluebbe]

Why do you use close_port_after_each_call=True?

[flxzt]

If I remember correctly: closing after each call leaves the port accessible for other users, otherwise it is locked.

[jluebbe]

@b2vn As you contributed the original Modbus RTU support in #806, do you have an opinion regarding this refactoring and my suggested approach in #1394 (review)?

[flxzt]

what's the resolution, I haven't heard from the original author that introduced local Modbus RTU support. @jluebbe

[codecov]

Codecov Report

❌ Patch coverage is 48.00000% with 26 lines in your changes missing coverage. Please review.
✅ Project coverage is 60.7%. Comparing base (e4f22e7) to head (ef10fd6).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
labgrid/driver/modbusrtudriver.py	46.6%	24 Missing ⚠️
labgrid/resource/modbusrtu.py	60.0%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           master   #1394     +/-   ##
========================================
- Coverage    60.7%   60.7%   -0.1%     
========================================
  Files         184     184             
  Lines       15099   15127     +28     
========================================
+ Hits         9180    9187      +7     
- Misses       5919    5940     +21     

Flag	Coverage Δ
3.10	60.7% <48.0%> (-0.1%)	⬇️
3.11	60.7% <48.0%> (-0.1%)	⬇️
3.12	60.7% <48.0%> (-0.1%)	⬇️
3.13	60.6% <48.0%> (-0.1%)	⬇️
3.14	60.6% <48.0%> (-0.1%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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