feat(inputs.rabbitmq): add support for head_message_timestamp metric

[philomory]

Required for all PRs:

• Updated associated README.md.
• Wrote appropriate unit tests.
• Pull request title or commits are in conventional commit format

resolves #11474

Adds support for the head_message_timestamp field to the rabbitmq_queue metric.

Note: This metric is only available from the API if there are messages in the queue, held in-memory by the broker, which have their timestamp metadata property set. The timestamp property can be set manually at time of message publication by the publisher, or it can be set automatically by the rabbitmq_message_timestamp plugin. Because the broker will not page messages in from disk just to read their timestamp, this metric is notably never present at the API for "lazy" queues (for which all messages are stored on disk and only loaded into memory briefly when a consumer grabs them). In cases where the head_message_timestamp field from the API is null, the head_message_timestamp field of the rabbitmq_queue measurement will simply be omitted.

[telegraf-tiger]

Download PR build artifacts for linux_amd64.tar.gz, darwin_amd64.tar.gz, and windows_amd64.zip.
Downloads for additional architectures and packages are available below.

👍 This pull request doesn't change the Telegraf binary size

📦 Click here to get additional PR build artifacts

Artifact URLs

DEB	RPM	TAR GZ	ZIP
amd64.deb	aarch64.rpm	darwin_amd64.tar.gz	windows_amd64.zip
arm64.deb	armel.rpm	darwin_arm64.tar.gz	windows_i386.zip
armel.deb	armv6hl.rpm	freebsd_amd64.tar.gz
armhf.deb	i386.rpm	freebsd_armv7.tar.gz
i386.deb	ppc64le.rpm	freebsd_i386.tar.gz
mips.deb	riscv64.rpm	linux_amd64.tar.gz
mipsel.deb	s390x.rpm	linux_arm64.tar.gz
ppc64el.deb	x86_64.rpm	linux_armel.tar.gz
riscv64.deb		linux_armhf.tar.gz
s390x.deb		linux_i386.tar.gz
		linux_mips.tar.gz
		linux_mipsel.tar.gz
		linux_ppc64le.tar.gz
		linux_riscv64.tar.gz
		linux_s390x.tar.gz
		static_linux_amd64.tar.gz

[powersj]

Thanks for the bug + PR outlining the purpose of this. This looks fine for adding an optional field for your use case.

[srebhan]

Thanks for the fix @philomory! Looks good to me.