Expand diagnostic report filename with id unique by the worker

What does this MR do and why?

Addresses #381689 (closed)

1. unique worker id (uuid) is added to the report filename.
2. the timestamp in the filename is human friendly

It would allow grouping all reports produced by the same Puma worker - so we could track the report data through the worker's lifetime. Otherwise, we can't be sure if two reports belong to the same Puma worker. The data we provide in the report filename was not enough to figure that out.

How to set up and validate locally

I suggest testing locally with GCK.
The reason is to pull the actual Jemalloc report, libjemalloc must be on LD_PRELOAD (more).

It is already configured in GCK this way.
On GDK in OSX, no reports will be produced.

1. On GCK, pull this branch: 381689-inject-correlation-id-into-diag-report-filename
2. Make sure you have GITLAB_DIAGNOSTIC_REPORTS_ENABLED set to true or hack the code to remove the check
3. Make sure report_jemalloc_stats feature flag is enabled or run Feature.enable(:report_jemalloc_stats) (or hack the check)
4. Switch to gitlab-rails app folder
5. Set smaller timeouts in lib/gitlab/memory/reports_daemon.rb, e.g:

      DEFAULT_SLEEP_S = 5
      DEFAULT_SLEEP_MAX_DELTA_S = 1
      DEFAULT_SLEEP_BETWEEN_REPORTS_S = 1

3. make web
4. After web started, docker exec -it gitlab-compose-kit_web_1 /bin/bash
5. Open the report path in the container (default is /home/git/gitlab/tmp/diag-reports)
6. Check that the reports are here and have unique worker id in the name (see screenshot).
7. You could also check that we log the same unique id under the perf_report_worker_uuid

Screenshots or screen recordings

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #381689 (closed)