Add hawkBit firmware management extension

[dominiquekleeven]

Closes #33

---

Adds a hawkBit firmware extension that connects OpenRemote Manager to the hawkBit Management API, exposes firmware management endpoints, and syncs selected OpenRemote assets as hawkBit targets.

Core Functionality

• Registers firmware meta items for marking assets as firmware targets (FIRMWARE_TARGET) and syncing selected attributes as hawkBit metadata (FIRMWARE_METADATA).
  • FIRMWARE_TARGET causes the asset to be synced as a target to hawkBit.
  • FIRMWARE_METADATA causes the attribute and its value to be synced as metadata to the target within hawkBit. This enables hawkBit to use attribute-aware target filters for grouping purposes.
• Creates, updates, and deletes hawkBit targets in response to OpenRemote asset events.
• Updates OpenRemote firmware target info attributes with hawkBit controllerId and securityToken.
• Proxies firmware management endpoints for targets, software modules, distribution sets, target filters, and rollouts.
• Adds OpenRemote read/write admin authorization and configured-realm access checks around firmware endpoints.
• Adds artifact upload support for hawkBit software modules. (required a bit of a workaround, but streams the uploaded file to the hawkBit endpoint).

Core Files

• HawkbitFirmwareService.java: Starts the integration, configures the hawkBit client, registers API resources, and handles asset/attribute sync.
• HawkbitResponseProxy.java: Copies hawkBit responses back through OpenRemote while preserving status, body, and media type.
• manager/hawkbit/*Client.java: RESTEasy clients for hawkBit Management API resources.
• manager/resource/*ResourceImpl.java: OpenRemote API resource implementations that authorize requests and proxy them to hawkBit.
• model/resource/*Resource.java: Public OpenRemote firmware endpoint definitions and role requirements.
• FirmwareMetaItemType.java: Defines firmwareTarget and firmwareMetadata meta items.
• FirmwareModelProvider.java: Registers firmware meta items with the OpenRemote model.
• README.md: Documents setup, limitations, API coverage, deployment examples, and proxy configuration.

Caveats

• The integration is currently limited to a single OpenRemote realm configured by HAWKBIT_REALM.
• This extension is intended to be used with the companion hawkBit/OpenRemote management UI service: https://github.com/openremote/service-hawkbit-ui

Testing

• Added mock based testing for checking whether asset events / attribute events trigger the appropriate 'client' call, e.g. sync behaviour.
• Added simple tests for the proxy behaviour.

Notes

• The large changed file count and addition count is mostly caused by license headers + model interfaces. The actual logic and behaviour is fairly minimal in terms of complexity/LoC.
• Not all hawkBit management API endpoints are integrated, only those who are deemed necessary to enable basic firmware/OTA management.

[dominiquekleeven]

Would be nice to get this merged fairly quickly as I want to deploy the extension to staging for a custom project. Happy to go through the additions/changes if needed.

[wborn]

This PR is being reviewed with AI first.

The overall extension structure and hawkBit integration look good. No definite blocking issues were identified, but there are a few lifecycle, security, and documentation points worth clarifying.

Inline comments contain the details.

[wborn]

The behavior when firmwareTarget or firmwareMetadata is removed from an existing asset or attribute does not appear to be documented. Currently, removing either marker stops synchronization but leaves the corresponding hawkBit target or metadata entry in place, whereas deleting the asset or attribute removes it.

Is that intentional? It would be useful to document the expected lifecycle when these meta items are removed and add tests covering those transitions.

[wborn]

This stores the hawkBit target security token in a normal asset attribute. Users who can read this asset can therefore obtain a credential that can authenticate as the target against the DDI API.

Is exposing the target credential to users with normal asset read access intentional? If not, a more restricted provisioning mechanism may be appropriate.

[wborn]

firmwareTarget requires a TEXT attribute because the service writes the JSON target information into it, but the README currently says it can be added to “one attribute”. Could the TEXT requirement be documented here and ideally validated by the service so a misconfigured asset fails clearly?