deck diff shows a diff for shorthand fields

[mheap]

When using a field defined as a shorthand_field in the Kong schema, deck shows a change in deck diff and deck sync even though the end result is the same.

Example using opentelemetry (schema):

Sample kong.yaml:

_format_version: '3.0'
plugins:
- name: opentelemetry
  config:
    endpoint: http://opentelemetry.collector.example.com:4318/v1/traces
    logs_endpoint: http://opentelemetry.collector.example.com:4318/v1/logs
    headers:
      X-Auth-Token: secret-token

❯ deck gateway sync kong.yaml
updating plugin opentelemetry (global)  {
   "config": {
     "batch_flush_delay": null,
     "batch_span_count": null,
     "connect_timeout": 1000,
     "header_type": "preserve",
     "headers": {
       "X-Auth-Token": "secret-token"
     },
     "http_response_header_for_traceid": null,
     "logs_endpoint": "http://opentelemetry.collector.example.com:4318/v1/logs",
     "propagation": {
       "clear": null,
       "default_format": "w3c",
       "extract": null,
       "inject": null
     },
     "queue": {
       "concurrency_limit": 1,
       "initial_retry_delay": 0.01,
       "max_batch_size": 200,
       "max_bytes": null,
       "max_coalescing_delay": 1,
       "max_entries": 10000,
       "max_retry_delay": 60,
       "max_retry_time": 60
     },
     "read_timeout": 5000,
     "resource_attributes": null,
     "sampling_rate": null,
     "send_timeout": 5000,
-    "traces_endpoint": "http://opentelemetry.collector.example.com:4318/v1/traces"
+    "traces_endpoint": null
+    "endpoint": "http://opentelemetry.collector.example.com:4318/v1/traces"
   },
   "enabled": true,
   "id": "4b3bafa3-eeba-43b1-95c2-ba6747ab184e",
   "name": "opentelemetry",
   "protocols": [
     "grpc",
     "grpcs",
     "http",
     "https"
   ]
 }

Summary:
  Created: 0
  Updated: 1
  Deleted: 0

Acceptance Criteria

• deck diff and deck sync do not show a diff when run

[Prashansa-K]

We have handled such cases for other plugins like rate-limiting. All shorthand_fields there had a "translate_backwards" property that we used to check if the new field is present, we don't show the diff for the deprecated one. For the Opentelemetry plugin schema, we don't have any translate_backwards property present, making this a special case. Added screenshots to showcase the difference in schemas.

Is this a major blocker for any customer? If yes, I am willing to handle it in a special manner. Otherwise, my preference would be to add a translation path in the backend schema, just like we have for others to maintain uniformity.
@mheap