Add OCPP 1.6 GetConfiguration and ChangeConfiguration support

[loosrob]

Add OCPP 1.6 GetConfiguration and ChangeConfiguration support

Summary

This PR adds two backend-initiated OCPP 1.6 messages that the server does not currently support:

• GetConfiguration – read a charge point's configuration keys (all, or a single named key)
• ChangeConfiguration – set a single configuration key to a new value

Both follow the existing pattern used by Reset, UnlockConnector, SetChargingLimit, etc.: an API endpoint on OCPP.Core.Server builds the request, sends it over the charge point's WebSocket, waits for the answer, and returns it to the API caller.

Motivation

Many chargers expose vendor-specific settings (e.g. dynamic load-management limits) as OCPP configuration keys. Without GetConfiguration/ChangeConfiguration there is no way to inspect or change these from OCPP.Core. In my case (an eNovates-based charge point) the dynamic load-balancing ceiling is the key MaxInstallationLoad, which is read/writable over OCPP but was previously unreachable.

New API endpoints

GET  /API/GetConfiguration/<chargePointId>              -> all keys
GET  /API/GetConfiguration/<chargePointId>/<key>        -> single key
GET  /API/ChangeConfiguration/<chargePointId>/<key>/<value>

Responses:

• GetConfiguration returns the raw OCPP GetConfiguration.conf payload:
  {"configurationKey":[{"key":"...","readonly":false,"value":"..."}],"unknownKey":[...]}
• ChangeConfiguration returns {"status":"Accepted"} (or Rejected / RebootRequired / NotSupported).

(Consistent with the existing convention, these use the URL segments already parsed by the middleware: urlConnectorId carries the key, urlParam carries the value for ChangeConfiguration; urlConnectorId optionally carries a single key for GetConfiguration.)

Files

New:

• OCPP.Core.Server/Messages_OCPP16/GetConfigurationRequest.cs
• OCPP.Core.Server/Messages_OCPP16/GetConfigurationResponse.cs
• OCPP.Core.Server/Messages_OCPP16/ChangeConfigurationRequest.cs
• OCPP.Core.Server/Messages_OCPP16/ChangeConfigurationResponse.cs
• OCPP.Core.Server/ControllerOCPP16.GetConfiguration.cs
• OCPP.Core.Server/ControllerOCPP16.ChangeConfiguration.cs

Modified:

• OCPP.Core.Server/ControllerOCPP16.cs – two case entries added to ProcessAnswer
• OCPP.Core.Server/OCPPMiddleware.OCPP16.cs – GetConfiguration16 and ChangeConfiguration16 sender methods
• OCPP.Core.Server/OCPPMiddleware.cs – two else if (cmd == ...) dispatch blocks in the /API handler

Scope note: this PR only implements the OCPP 1.6 path. The OCPP 2.0/2.1 controllers are untouched (the dispatch returns 501 Not Implemented for those protocols), matching how some other commands are staged.

Testing

Built from source and run against a live eNovates-based charge point (OCPP 1.6J):

$ curl -s -H "X-API-Key: ..." ".../API/GetConfiguration/<cp>/MaxInstallationLoad"
{"configurationKey":[{"key":"MaxInstallationLoad","readonly":false,"value":"20.00"}]}

$ curl -s -H "X-API-Key: ..." ".../API/ChangeConfiguration/<cp>/MaxInstallationLoad/21.00"
{"status": "Accepted"}

$ curl -s -H "X-API-Key: ..." ".../API/GetConfiguration/<cp>/MaxInstallationLoad"
{"configurationKey":[{"key":"MaxInstallationLoad","readonly":false,"value":"21.00"}]}

The full-configuration read (GetConfiguration with no key) also returns the complete key list from the charger.

Documentation

Server-API.md is updated with the two new endpoints (see Server-API.additions.md in this package for the text to merge).

Notes / open questions for the maintainer

• No JSON schema files were added under Schema16/ for the new messages. DeserializeMessage<T> already falls back to schema-less deserialization when a schema file is absent, so validation is simply skipped for these two. Happy to add GetConfigurationResponse.json / ChangeConfigurationResponse.json schemas if you'd prefer validation.
• During testing I hit a separate, hardware-specific correlation issue where this particular firmware truncates the echoed OCPP UniqueId. That is not part of this PR (it does not affect KEBA or spec-compliant chargers). It is documented separately in UNIQUEID_NOTE.md in case it's of interest, but I've deliberately kept it out of this change so the feature can be reviewed on its own.

Licensed under GPLv3, consistent with the rest of the project. File headers copied from existing files.