Fix reply correlation and failure reporting

[glopesdev]

A reply could satisfy the wrong request. Pending requests were keyed by address alone, so a Read and a Write on one register would answer each other. This needs no concurrency, since a write that times out followed by a read returns the late write reply as the read result, with nothing raised.

Three changes follow from that, all inside Device. The public surface gains one name, DeviceError, and nothing else moves, since REPLY_TIMEOUT, raise_on_error, the ITransport contract and TransportError are untouched. Eight tests drive all of it through a scripted transport that replies from inside write, so a reply is never dispatched before its waiter exists and no test depends on timing.

Correlating a reply with its request

Requests are keyed by address and message type, and each key holds every waiter. Bonsai.Harp has always done this, filtering on message.IsMatch(command.Address, command.MessageType) and subscribing before it writes.

The wire carries no request identifier, so two identical requests in flight stay indistinguishable in the reply. The only difference is that both waiters are now satisfied by one reply instead of one being stranded on a replaced waiter.

Reporting a failure instead of losing it

A TransportError raised inside the reader thread was re-raised there and lost, since the thread is a daemon with nobody watching, so a removed port presented as a device that had gone quiet and every later call blamed a timeout. It is now reported to every waiting request and recorded, so a later request fails with the actual cause. The C# read loop calls OnError on its response subject for the same reason.

An error reply raised RuntimeError with the frame formatted into the message string and then discarded. It now raises DeviceError, which keeps the reply as reply, so a caller can inspect what the device actually sent. A conformance check needs exactly that to assert which error a device gave.

[bruno-f-cruz]

I may be misunderstanding this and I can try later, but can we add a test that checks whether a single reply satisfies multiple requests?

For instance
Read(44)
Read(44)

Reply(44) <consumes both

Which shouldn't happen

[bruno-f-cruz]

I may be misunderstanding this and I can try later, but can we add a test that checks whether a single reply satisfies multiple requests?

For instance
Read(44)
Read(44)

Reply(44) <consumes both

Which shouldn't happen

Actually nvm. The current api is blocking so this should not happen. Maybe something to worry about if we go asyn