Support message headers

[kwitekrac]

Description

This PR introduces support for using message headers in the publish and consume functions.

Important notes

• The header keys and values are exposed as strings in the functions that LabVIEW will call. However, it's essential to note that in the C library, headers have specific value types, and currently, only "AMQP_FIELD_KIND_BYTES" (unformatted byte strings) is supported.
• Transmitting and receiving an array of strings between LabVIEW and a shared library can present challenges. Therefore, our approach involves concatenating the strings within the array into a single string before transmission.
• Additionally, the "queue create" function no longer automatically binds the queue; it now has its own separate method called "bind queue."

Related Issues

Checklist

• I have used a PR title that is descriptive enough for a release note.
• I have tested these changes locally.
• I have added appropriate tests or updated existing tests.
• I have tested these changes on a dedicated VM or a customer VM [name of the VM]
• I have added appropriate documentation or updated existing documentation.

[chicco785]

I have not knowledge on LabVIEW side to comment on integration aspects. As regards that I fully trust you :)

My only concern relates to the usage of separate arrays for keys and values, that if for any reason (e.g. no value) ends being of different length may result in some memory leak (and unwanted behaviour).

[AntoineChalons]

a few thoughts about headers :

• adding support for all the possible types is a nice effort but not required at this point, it's if done, then good, if it still requires work, let's put it on hold
• the only header that has to be read on the LabVIEW side for each timestamp (therefore at 50/60Hz) is the 'timestampId', so for this header it makes sense to put it as int64 (ou uint64), for the others there will be no impact on perf if they are passed as string and need to be type-cast on the LabVIEW side (it is the case for trigger header messages)

[kwitekrac]

a few thoughts about headers :

• adding support for all the possible types is a nice effort but not required at this point, it's if done, then good, if it still requires work, let's put it on hold
• the only header that has to be read on the LabVIEW side for each timestamp (therefore at 50/60Hz) is the 'timestampId', so for this header it makes sense to put it as int64 (ou uint64), for the others there will be no impact on perf if they are passed as string and need to be type-cast on the LabVIEW side (it is the case for trigger header messages)

If you think about receiving the data, you also need to consider the type header that is sent as I8. Kevin will start working with Sending Messages from FL -> that will require to send UTF8. That is why I put a lot of effort into implementing most of the types that are defined in the library. At this point, only the following types are not supported:

• AMQP_FIELD_KIND_BOOLEAN
• AMQP_FIELD_KIND_DECIMAL
• AMQP_FIELD_KIND_ARRAY
• AMQP_FIELD_KIND_TABLE
• AMQP_FIELD_KIND_VOID

as I cannot see the use case on our side.