Check authorization in Basics Station discovery

[adriansmares]

Summary

References https://github.com/TheThingsIndustries/lorawan-stack-support/issues/1007
References https://github.com/TheThingsIndustries/lorawan-stack/pull/3974

Changes

• Allow individual gateway protocol frontends to assert the rights of the caller, without connecting per se as the gateway.
• Assert that the caller has the required rights over a gateway while calling the LNS discovery endpoint.
  • Currently, the gateway doesn't realize that its credentials may need to be updated, because the LNS gives mixed signals - it accepts the credentials during discovery, but not during traffic. As such, the gateway falls back to doing a discovery round again, instead of doing a CUPS lookup.
  • The changes proposed here allow the gateway to correctly fall back to CUPS in order to update both its credentials and the LNS address.

Testing

Unit tests and local testing. This is currently live on staging1.

Testing steps:

1. Register a Basic Station gateway using CUPS.
2. Connect said gateway.
3. Invalidate (delete or just remove the linking right) the LNS key.
4. Generate new LNS key and set it as LNS key.
5. Trigger a gateway reconnect remotely (i.e. toggle the 'disable Packet Broker forwarding' option).
6. Expect the gateway to reconnect using the new LNS key before the next periodic CUPS lookup (i.e. in less than 24 hour, preferably way faster).

Regressions

All of the implementations derived form the Semtech reference implementation provide the credentials during discovery. Tektelic also provides the credentials during discovery. So does Kerlink.

I've ran the above test sequence for all of the vendors.

Kerlink unfortunately doesn't re-trigger CUPS if discovery fails, but that's unrelated to this fix. They run CUPS periodically every hour, so should someone need to migrate, it should more manageable. For reference, the reference implementation runs CUPS every 24 hours if discovery never fails.

Notes for Reviewers

We cannot unfortunately return a 'good' HTTP status code, as the gateway identifiers are not available before the WebSocket upgrade occurs. We have to return the error via WebSockets.

No need to review.

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.
• The steps/process to test this feature are clearly explained including testing for regressions.
• 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.