integrationtest to verify limits of iceoryx

Brief feature description

In iceoryx_posh_types.hpp defines maximum supported amounts of resources like ports, history size, mempools, shared memory segments etc. free to use by the user.

We require tests to check if those limits are compatible with each other and maybe connect them with if necessary. Additionally, we require integrationtests which verify that iceoryx runs stable even when all resources are in use.

Detailed information

In a first step it would make sense to split up iceoryx_posh_types.hpp into a iceoryx_config.hpp file and into a compile time iceoryx_config_verificator.hpp. In the config file only the global constexpr are defined and we put all the static_asserts into the verification file. All the remaining class and function definitions have to be moved to more fitting places. Maybe a iceoryx_common.hpp file would make sense. Finally, when having tightly coupled MAX_ values then only one of those values should be present in iceoryx_config.hpp. The coupling of the other value should happen in iceoryx_config_internal.hpp so that the user cannot create incompatible configurations.

List of coupling problems (not complete):

Can we move certain MAX_ values to platform_settings.hpp since most system resources have platform specific limits
Maximum amount of publishers and maximum amount of supported entries in service registry must be equal
When pursuing approaches for pub/sub find service: max number of apps and max number of subscribers per publisher must be equal
Do we really require a maximum history size of 2048 when there is no mempool with 2048 chunks of a specific size? A user would get an out of chunks error before the history is completely filled
Does it make sense to couple maximum chunks hold in parallel to the history size?
Do we require global MAX_* specifications for message queues in there. This is an implementation detail which is platform dependent. Could this be integrated into the posix wrapper?

Internally used resources

A user does not know what kind of resources we are using internally. So it may happen that they are surprised that they configured 6 publishers but they can only create 1 (since the remaining 5 are used by the introspection). This can be solved by having a MAX_PUBLISHERS variable in the public iceoryx_config.hpp and a MAX_PUBLISHER_IN_SYSTEM=MAX_PUBLISHER + PUBLISHERS_USED_BY_INTROSPECTION in the iceoryx_config_internal.hpp.

But still it may happen that a user then breaks its own contract and uses more publishers than configured and maybe internal services are then crashing. In a further step it may makes sense to decouple internal resources completely so that they are always available for roudi.

To Do

[ ] Split up iceoryx_posh_types.hpp into iceoryx_config.hpp, iceoryx_config_verification.hpp, iceoryx_config_internal.hpp and iceoryx_common.hpp
[ ] Couple internally used resources with public configuration. See MAX_PUBLISHER_IN_SYSTEM=MAX_PUBLISHER + PUBLISHERS_USED_BY_INTROSPECTION
[ ] Write small integration tests first where only a single limits are verified. If we encounter here that certain values are coupled combine those values in either one value (if they are equal) or define the one with the other outside of the config where it is needed. When having coupled config entries only one should be available for the user the other one should be configured internally with the coupling it requires.
[ ] Write single integration tests which tests the maximum of everything.
[ ] MAX_NUMBER_OF_NOTIFIERS_PER_CONDITION_VARIABLE, MAX_NUMBER_OF_EVENTS_PER_LISTENER, MAX_NUMBER_OF_ATTACHMENTS_PER_WAITS should be reasonable coupled to the maximum allowed ports (subscriber/publisher/service/client). Since some users may would like to handle the whole communication over a waitset/listener. See: #1109
[ ] MAX_NUMBER_OF_NOTIFIERS_PER_CONDITION_VARIABLE, MAX_NUMBER_OF_EVENTS_PER_LISTENER, MAX_NUMBER_OF_ATTACHMENTS_PER_WAITS should be configurable via CMake

eclipse-iceoryx / iceoryx