Memory Config Timeout Support (Datagrams)

[bakerstu]

• Added support on the server side.
• Added support on the client side.
• Added unit test coverage.

[atanisoft]

Looks good, will do some testing over this weekend.

@bobjacobsen can you confirm if JMRI is similarly handling timeout hints on datagram responses so I can test through that as well?

[bobjacobsen]

can you confirm if JMRI is similarly handling timeout hints on datagram responses so I can test through that as well?

@atanisoft I'm away from my setup at the moment, but I don't think JMRI (OpenLCB_Java) is doing this correctly. Will check, but it might be a day or two. If not, that needs to be fixed. There are some other things in the handling of the memory configuration protocol that need fixing too, so I'll try to do them all at the same time.

[atanisoft]

With the latest code I'm seeing the following warning/deprecation notice:

src/openlcb/MemoryConfig.hxx:1011:43: warning: bitwise operation between different enumeration types ‘openlcb::DatagramClient::ResponseFlag’ and ‘openlcb::DatagramDefs::Flag’ is deprecated [-Wdeprecated-enum-enum-conversion]
 1011 |             DatagramClient::REPLY_PENDING | space->get_write_timeout());

Not sure how best we should handle this other than using casting to an integer and then back to ResponseFlag.

[bakerstu]

With the latest code I'm seeing the following warning/deprecation notice:

src/openlcb/MemoryConfig.hxx:1011:43: warning: bitwise operation between different enumeration types ‘openlcb::DatagramClient::ResponseFlag’ and ‘openlcb::DatagramDefs::Flag’ is deprecated [-Wdeprecated-enum-enum-conversion]
 1011 |             DatagramClient::REPLY_PENDING | space->get_write_timeout());

Not sure how best we should handle this other than using casting to an integer and then back to ResponseFlag.

@atanisoft This is a good find. We should fix this. I can think of three possible solutions:

1. Static cast the operation.
2. Create a custom operator override.
3. Rework the enumerated types to be a bit more consistent and compatible, maybe even built off each other a bit. Possibly consider structs with bitfields.
   1. This would still likely require some custom operator overrides.
   2. One problem with bitfields is that there is no standard bit ordering enforced by the C/C++ standards. It happens that pretty much everyone uses the same order though, so maybe this is not so much an issue.

I very much would like to cleanup these enumerated types. I think they are not very well laid out, and could have been better designed. That said, I think it is too much of a change at this point. Therefore, I prefer solution 1. It is brute force, but at least self documenting in what the operation is doing.

WDYT?

[atanisoft]

I'm fine with opting for static_cast for now and seeing what we can do outside this PR as a better fit. I know C++20 has a bit better handling of enums, which may rely on extending standard variable types like uint8_t or similar.

[bakerstu]

I added the static_cast for both read and write timeout cases.

[balazsracz]

if the read finishes upon the first attempt, the timer is never started.
If this code is really needed, then we have to call timer_.set_triggered() on that path.

[bakerstu]

It is definitely required. Unit testing proves that. I think modifying the statement to (isWaitingForTimer_ == true && !timer_.is_triggered()") is an adequate fix though.