Implement QR Code Parser Service

[KrishnaIyer]

Summary

Implement QR Code Parser Service. Closes #4845 .

Changes

• Refactor qrcode and qrcodegenerator package.
• Add a new EntityOnboardingData message with EndDeviceOnboardingData as the first type.
• Add a QRCodeParser service an implement the server.
• Adapt DCS to dial QRG.
• Adjust tests.

Testing

Unit tested.

Regressions

I don't expect any.

Notes for Reviewers

1. The QRG will now be the single point of truth for QR code formats. So I've moved the qrcode package into qrcodegenerator, so that components don't call the functions separately but dial QRG instead.
2. I don't see a use case where someone wants to parse a QR Code via the CLI; so I haven't added a command for this. We also don't claim using QR codes in the CLI. However, if we need a command for completeness, I can add that.

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.

[johanstokking]

Reviewed API only for now

[nicholaspcr]

The DCS section LGTM.

[htdvisser]

Only looked at api. Not much to add on top of @johanstokking's comments at this point.

[KrishnaIyer]

@johanstokking Regarding the comment on EndDeviceTemplate.

Step 1 of the new onboarding flow says; #4847 (comment) (line numbers are mine)

a. Scan QR code: this contains at least the JoinEUI and DevEUI, potentially also the numeric Vendor and Profile ID and the Claim Authentication Code. Call the QRCodeParser.Parse() rpc (https://github.com/TheThingsNetwork/lorawan-stack/issues/4845)
b. Put the JoinEUI and DevEUI in the onboarding state
c. If the QR code contains a claim authentication code, put this in the onboarding state
d. If the QR code contains a non-zero Vendor ID and Profile ID, lookup the LoRaWAN device profile (https://github.com/TheThingsNetwork/lorawan-stack/issues/4842) and put this in the onboarding state. Otherwise, the LoRaWAN device profile is empty, but the activation mode can be preset to OTAA (ABP devices won't have QR codes)

So the QR Code is scanned and we only need the EUIs, CAC and the Vendor/Profile IDs. We then use this data in separate RPCs.

Theoretically, if we have the AppIDs and the above Vendor/Profile IDs, we can dial the Device Repository and get the End Device Template but this will be done further in the end device creation flow when the user chooses the region/firmware etc (Step 2 of onboarding flow).

a. So do we really need to use End Device Templates here? Because, if the QR Code does not have Vendor ID and Model ID, in that case wouldn't return a mostly empty End Device (Template) with just the EUIs and CAC?
b. I can update the fields of the EndDeviceOnboardingData to remove the TR005-only fields. But what do we do with those fields? Do we just discard them and only return what's needed for onboarding? Ex: Do we verify this checksum anywhere?

The way I understood the issue, we only need to parse the QR Code and return the data in a generic format and let the
caller call other RPCs with the returned data (For example use Vendor ID/ Model ID and the DR for the device profile).

[johanstokking]

a. So do we really need to use End Device Templates here? Because, if the QR Code does not have Vendor ID and Model ID, in that case wouldn't return a mostly empty End Device (Template) with just the EUIs and CAC?

There may be other QR codes in the future with additional fields. Also, as we don't have a formal serial number field currently, we probably want to put it in an attribute. End device templates are really designed for this.

b. I can update the fields of the EndDeviceOnboardingData to remove the TR005-only fields. But what do we do with those fields? Do we just discard them and only return what's needed for onboarding? Ex: Do we verify this checksum anywhere?

See TR005 1.0 spec:

210 The Checksum is used to validate the data integrity. Even though QR codes have their own
211 built-in integrity checks, this explicit checksum is useful when the content of the QR code is
212 presented as plain text. Checksum is generated using the CRC-16-MODBUS [CRC] of the
213 full QR content except the Checksum field itself, and presented in hexadecimal format
214 without the leading “0x”.

So the TR005 parser should verify it, and after that, it's not of any use anymore.

The way I understood the issue, we only need to parse the QR Code and return the data in a generic format and let the caller call other RPCs with the returned data (For example use Vendor ID/ Model ID and the DR for the device profile).

Yes. So the response would be a oneof with EndDeviceTemplate as one of the options.