Add dcp support fixes for Linux/Docker

[alexandernikolic-v2c2]

Necessary fixes to be able to build it on Linux/podman(alias docker)
Built and Tests ran in a container using podman.
Replace any podman occurences with docker and you should be fine.

Also make sure the file install/dcp/cosine/slave.dcpx exists before running any tests.

Find scripts attached:

podman.sh // building the image, running the container in a way it won't interfere with gdb in case you want to debug using gdbserver
openmcx_build_with_dcp_dbg.sh // OpenMCx building with DCP Support and DCPLib building - Debug mode
openmcx_build_with_dcp_rel.sh // OpenMCx building with DCP Support and DCPLib building - Debug mode
openmcx_debug_dcp.sh // Running openmcx with the dcp_fmu/model.ssd after starting slave-cosine in background
openmcx_run_tests.sh // Running run_tests.py after starting slave-cosine in background as seen in github workflow

helperscripts.zip

[alexandernikolic-v2c2]

For further information you might also want to look into the logs and binaries attached here:
successful_release_run.zip

[alexandernikolic-v2c2]

Some irreproducible error might happen after

Warning: Sinus 1: fmi2_xml_get_default_experiment_tolerance: returning default value, since no attribute was defined in modelDescription
Starting DCP master
Slave network setup started
Slave network setup done
Registering DCP slaves started

With an Error that a timeout was reached.

Changing the Master::timeout_ to a higher value and recompiling the openmcx binary removed the error permanently.
Even after undoing the change and recompiling again.
I have no more useful information on that except the function/line in question:

master.cpp:577:process_response:"//check whether the timeout was reached"

[klausschuch]

wouldn't it be enough to just use this for both platforms?

[alexandernikolic-v2c2]

I cannot say for sure, because I do not have the (same) resources at the moment to test this the way you test it.
I decided to make a non-invasive change.

I know from my last commit that vcpkg occasionally uses different names and naming-schemes for packages than other package management systems and that the generated CMake-related files may not be working with the default names.