Fix unexpected RekeyInd handling

[adriansmares]

Summary

This PR makes our handling of RekeyInd a bit smarter by discarding RekeyInd commands which are unexpected (specifically, if the LNS did not set the OptNeg bit during the Join Request handling).

This has showed up during some accidental fuzz testing - random bytes on FPort 0 are sent by the end device, and the LNS parses them as legitimate commands. A possible such command is RekeyInd, which switches the LoRaWAN version of the MAC state. If a 1.0.x end device sends this command, we must always discard it, otherwise we risk failing to match the packet (because the requested minor may be higher than 1, and thus enable the 1.1+ extra MIC checks).

Changes

• Discard unexpected RekeyInd commands.
• Change the error code for the unimplemented rejoin-request handler. Unimplemented errors are reported to Sentry and are logged with error level, as they generally signal some deep version mismatch, but the unimplemented state here is intentional.

Testing

Local testing. This feature does not require explicit testing.

Regressions

The RekeyInd commands will now be rejected if the end device version is < 1.1+, which is the correct behavior anyway.

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.