Fix handling Service Ping response with only usage_data_id

What does this MR do and why?

Related to #337497 (closed)

https://gitlab.com/gitlab-services/version-gitlab-com/-/merge_requests/630 fixed Version App not sending usage_data_id when there's not enough payloads from a given GitLab instance to send back full DevOps metrics in a conv_index Hash. This only happens for a very first Service Ping from a new instance.

This turned out to not be enough to fix #337497 (closed) and ServicePing::SubmitService now tries to save an empty DevOpsReport::Metric record when only usage_data_id is present in a response.

This MR fixes this behavior by omitting usage_data_id in a check if metrics are present in a response.

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

1. Reset GDK data with gdk reset-data
2. Set ServicePing::SubmitService.base_url to point to your local Version App instance.
3. Send Service Ping to local Version App instance by running ServicePing::SubmitService.new.execute

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.

app/services/service_ping/submit_service.rb

@@ -78,7 +78,7 @@ def save_raw_usage_data(usage_data)
     def store_metrics(response)
       metrics = response['conv_index'] || response['dev_ops_score'] # leaving dev_ops_score here, as the response data comes from the gitlab-version-com
 
-      return unless metrics.present?
+      return unless metrics.except('usage_data_id').present?
 
       DevOpsReport::Metric.create!(
         metrics.slice(*METRICS)