POST /api/v2/status/service fails for OpenVPN instances when more than one exists ("Field name must be unique") #953

Describe the bug

With two or more OpenVPN instances (for example one server and one client), every start/stop/restart of any of them through POST /api/v2/status/service is rejected with a validation error. Other services, including IPsec and WireGuard, work.

To Reproduce

1. Configure one OpenVPN server and one OpenVPN client (or two servers).
2. GET /api/v2/status/services lists both under the same name:

   {"id": 7, "name": "openvpn", "description": "OpenVPN server: test server", "enabled": true, "status": true}
   {"id": 8, "name": "openvpn", "description": "OpenVPN client: test client", "enabled": true, "status": true}

3. POST /api/v2/status/service with {"id": 7, "action": "restart"}
4. See the 400 response below. The same happens for {"id": 8, ...}; {"name": "openvpn", "action": "restart"} returns Field 'id' is required.

Expected behavior

The service identified by id is restarted, as it is for services with a unique name (e.g. {"id": 6, "action": "restart"} on ipsec works).

Screenshots or Response

HTTP 400
Field `name` must be unique. Value is in use by object with ID `8`.

pfSense Version & Package Version:

• pfSense Version: pfSense CE 2.8.1-RELEASE (amd64)
• Package Version: v2.10.2

Affected Endpoints:

• URL: /api/v2/status/service (POST)

Cause (as far as I can tell)

Models/Service.inc declares the name field with unique: true. The service list legitimately contains several entries with the same internal name (pfSense runs one openvpn service per instance and passes the instance via the extra vpnid data, which _format_extra_data() already handles), so the uniqueness check fails before _create() is reached.

Dropping unique: true from name (or excluding it from validation for this model) should be enough, since the record is addressed by id anyway.

Related observation

The id of a service is its position in the list, so it shifts when a package adds or removes a service (installing WireGuard moved every other service up by one). API clients have to re-read the list right before each action to avoid acting on the wrong service. A stable identifier, or accepting name plus vpnid for OpenVPN, would make this safer.

Additional context

Found while building an ioBroker integration on top of the REST API (thank you for the package, it covers almost everything we needed).