Fix memory limit for RssMemoryLimit monitor

What does this MR do and why?

In !102300 (merged) we introduced RssMemoryLimit monitor as backward compatibility monitor to PumaWorkerKiller

In !103472 (merged) we enabled Watchdog by default to be used instead of PumaWorkerKiller for our self-managed customers.

The RssMemoryLimit compares Gitlab::Metrics::System.memory_usage_rss[:total] which is measured in bytes against provided memory_limit. The issue is that we are passing memory_limit in megabytes.

This MR converts provided memory limit to bytes, so we could compare provided memory limit with current worker RSS in bytes.

Impact

Gitlab.com - is not affected, Watchdog is using HeapFragmentation and UniqueMemoryGrowth monitors since PumaWorkerKiller is disabled by default

Self-managed customers using Omnibus and using release 15.6 are affected since they have PumaWorkerKiller enabled by default.

Everyone that enabled PumaWorkerKiller are also affected.

The effect

The Watchdog will gracefully restart puma worker every 5 minutes.

From user perspective, it will result in increased latencies and likely a decreased request throughput for the GitLab instance.

From the instance administrator perspective, they should see log records about Puma workers restarted because out of memory.

Workaround

Customers can set: GITLAB_MEMORY_WATCHDOG_ENABLED to false.

In Gitlab.com and saas, we

This MR fixes and converts memory limit configured with PUMA_WORKER_MAX_MEMORY env variable to bytes

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

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: #383440 (closed)