Fix the verdict on a pod's resource settings

You asked an assistant to add resource limits to a JVM service's pod spec. It requested 2 CPU cores with a limit of half a core, and 256 MiB of memory with a limit of 4 GiB. The pod gets OOMKilled (killed for using too much memory) under load. The team now checks every pod spec's numbers for a verdict. A request is what the scheduler reserves for the container. A limit is the most it may use.

An assistant wrote pod_resource_verdict(cpu_request, cpu_limit, memory_request, memory_limit). It is in the editor. It has a bug. Find it and fix it.

Input and output:

• cpu_request, cpu_limit: CPU quantities as strings. Digits alone are whole cores, so "2" is 2000 millicores. Digits followed by m are millicores, so "500m" is 500.
• memory_request, memory_limit: memory quantities as strings, digits followed by Mi or Gi. "1Gi" is 1024 Mi.
• An empty string means the value is not set.
• Return one verdict string, from the list below.

Rules the tests check:

• The digits are ASCII 0 to 9 only, at least one. Anything else that is not empty, such as "abc", "1.5", "256M" or "1gi", makes the verdict "invalid_quantity". This check comes first.
• Then fill in missing requests: a request that is not set takes its limit's value, if the limit is set. A limit that is not set stays not set. That is how Kubernetes does it.
• Then return the first verdict that applies, in this order:
  1. "invalid_cpu": both CPU values are set and the request is above the limit.
  2. "invalid_memory": both memory values are set and the request is above the limit.
  3. "besteffort": none of the four values is set.
  4. "guaranteed": both limits are set, and each request equals its limit.
  5. "oomkill_risk": the memory request is set and above 0, the memory limit is set, and the limit is at least 4 times the request.
  6. "burstable": anything else.
• Compare quantities after converting them: CPU in millicores, memory in Mi.