Replace x-medkit response extensions with dedicated REST resources

[bburda]

Summary

Remove x-medkit extension fields from SOVD API responses and replace them with dedicated REST resources. Currently, ROS2-specific metadata is embedded in responses via x-medkit object, which pollutes the standard SOVD response schema. Instead, we should expose this data through separate endpoints following REST resource patterns.

---

Current approach (to be removed)

// GET /api/v1/apps/temp_sensor/data/temperature
{
  "id": "temperature",
  "name": "Temperature",
  "value": { "data": 25.5 },
  "x-medkit": {
    "ros2_topic": "/powertrain/temperature",
    "message_type": "std_msgs/msg/Float64",
    "qos": { "reliability": "reliable", "durability": "volatile" },
    "schema": { "type": "object", "properties": { ... } }
  }
}

---

Proposed solution

Replace x-medkit inline extensions with dedicated sub-resources:

1. ROS2 Topic Information

GET /api/v1/{entity-path}/x-ros2-topic

Returns ROS2-specific topic metadata:

{
  "topic_name": "/powertrain/temperature",
  "message_type": "std_msgs/msg/Float64",
  "qos": {
    "reliability": "reliable",
    "durability": "volatile",
    "history": "keep_last",
    "depth": 10
  },
  "publishers": ["/temp_sensor_node"],
  "subscribers": []
}

2. Type Schema

GET /api/v1/{entity-path}/x-ros2-typeschema

Returns JSON Schema for the data type:

{
  "type": "object",
  "properties": {
    "data": {
      "type": "number",
      "format": "float64"
    }
  },
  "required": ["data"]
}

3. Additional ROS2 Resources (future)

GET /api/v1/{entity-path}/x-ros2-node        # Node info for apps
GET /api/v1/{entity-path}/x-ros2-service     # Service info for operations
GET /api/v1/{entity-path}/x-ros2-action      # Action info for long operations
GET /api/v1/{entity-path}/x-ros2-parameter   # Parameter info for configurations

---

Benefits

• SOVD compliance: Response bodies match standard SOVD schema exactly
• Separation of concerns: ROS2-specific data is clearly separated from SOVD data
• Discoverability: Clients can discover available extensions via resource links
• Cacheability: Extension data can be cached independently
• Flexibility: Easy to add new extension types without modifying core responses

---

Additional context

• Affects all entity types: areas, components, apps, data, operations, configurations, faults
• Consider expanding entity capabilities
• Consider adding _links to responses pointing to available extensions (HATEOAS pattern)