Fix for issue 416: Impossible to retain transfer ids

[serges147]

• Introduced public ITransferIdMap and internal detail::ITransferIdStorage interfaces.
• Presentation publisher and rpc client entities now...
  • try initialize (at ctor) their transfer ids with the transfer id map getIdFor method.
  • try to store their next transfer ids into the map (using setIdFor).
• Extra unit tests and mocks to cover new transfer id map related business logic.

[serges147]

JFYI, this is not a new file, but rename and a bit modification of the above transfer_id_generators.hpp

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
98.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[thirtytwobits]

We probably should mention that these generators are not thread-safe

[serges147]

Whole libcyphal is not thread-safe.

[thirtytwobits]

I think we're getting a little too OOP here. The map type should be STL-compliant and defined in config.hpp (see #419). We can use cavl to implement a cetl::pmr O(log n) implementation that is enough of a std::map duck type to cover our use cases and users can chose to redefine to std::pmr::unordered_map when using C++17.

[serges147]

Maybe if such type will be just memory-only container. But...

1. the idea is to have persisting when needed
2. currently interface is very clear. without c++20 concepts it becomes very blurry (should I use operator [] or insert/remove, and so on...)
3. in unit tests I have and use gmock of the interface - gives me very nice observability with minimum efforts
4. this is optional feature of libcyphal - it works totally fine without it
5. how much do you really save avoiding one virtual call for such relatively rare operations...?
6. it's so easy to write a simple wrapper around whatever already existing STL collection. I can even add an example in the docs if you think it could be a showstopper for the user.
7. config.hpp is relatively hardcore feature - you normally switch it on or off for the whole project; you can't have it on and off in one single cpp unit as I DO need in tests. That is why f.e. I have one special dedicated test/unittest/presentation/test_publisher_custom_config.cpp source file.

So, IMHO we should not complicate things.

[thirtytwobits]

Okay. You've convinced me.