[21393] Add new tests for testing new key hash calculation according to DDS-XTypes 1.3

[richiware]

Description

This PR increases the number of tests of the DynamicTypes feature for testing the new key hash calculation according to DDS-XTypes 1.3

Depends on:

• [21392] Refactor key hash calculation according to DDS X-Types 1.3 Fast-DDS-Gen#381

Contributor Checklist

• Commit messages follow the project guidelines.
• The code follows the style guidelines of this project.
• Tests that thoroughly check the new feature have been added/Regression tests checking the bug and its fix have been added; the added tests pass locally
• N/A Any new/modified methods have been properly documented using Doxygen.
• N/A Any new configuration API has an equivalent XML API (with the corresponding XSD extension)
• N/A Changes are backport compatible: they do NOT break ABI nor change library core behavior.
• Changes are API compatible.
• N/A New feature has been added to the versions.md file (if applicable).
• N/A New feature has been documented/Current behavior is correctly described in the documentation.
• N/A Applicable backports have been included in the description.

Reviewer Checklist

• The PR has a milestone assigned.
• The title and description correctly express the PR's purpose.
• Check contributor checklist is correct.
• N/A: If this is a critical bug fix, backports to the critical-only supported branches have been requested.
• Check CI results: changes do not issue any warning.
• Check CI results: failing tests are unrelated with the changes.

[MiguelCompany]

LGTM with green CI

[MiguelCompany]

LGTM with green CI

[Mario-DL]

These former commits propose a fix for the DDSTypesTest_KeyedLongDoubleStruct test which was failing only in ubuntu github ci, not being reproducible in local.

sizeof(long double) is meant, to at least, have 8 bytes. However, its typical values are 10, 12 or 16.
Fast CDR detects system's size for long double and uses it in consequence.
The problem that came was that, despite the system returns that supports a size of 16 for a long double, experimental analysis revealed that the 6 least significant bytes after reinterpret_cast<const char*>() of a long double were trash or, at least subject to rounding issues. The following link leads to a simple script in godbolt. By running multiple times, the least 6 significant bytes change from one run to another but, the reconstructed value remains always the same.

Bearing this in mind, the proposed fix makes the test only compare the first 10 bytes of the structure (in reality, the latter 10 bytes since the key hash is computed with BIG_ENDIAN).
It can be discussed that we could change the logic also in Fast CDR but from my point of view it is doing things coherently in the sense that it is serializing the full 16 bytes, because it is what the system says it supports for a long double.