Fix overrun when receiving debug packet (0xFF) in debug builds

[twostars]

We raise it to effectively support a total of 256 opcodes instead of 255, as 0~255 inclusive = 256 opcodes, causing it to overrun when sending/receiving the N3_TEMP_TEST packet.

Your checklist for this pull request

🚨Please review the guidelines for contributing to this repository.

• [x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). Don't request your master!
• [ x Make sure you are making a pull request against the canary branch (left side). Also you should start your branch off our canary.
• [x] Check the commit's or even all commits' message styles matches our requested structure.
• [x] Check your code additions will fail neither code linting checks nor unit test.

Description

This fixes an overrun when receiving the debug packet (N3_TEMP_TEST / 0xFF) in debug builds. We raise it to effectively support a total of 256 opcodes instead of 255, as 0~255 inclusive = 256 opcodes, which originally caused it to overrun when sending/receiving the N3_TEMP_TEST (0xFF) packet.

💔Thank you!

[twostars]

+1 (256) fixes the issue

I am aware, since I was the one that debugged and fixed this for you. It felt more appropriate in this case to use UCHAR_MAX to represent the max potential opcode size, given they're unsigned bytes.

I would have moved the opcodes into an enum and done it that way, but didn't want any linting concerns, nor am I familiar with the expected naming conventions here. So I resorted to using UCHAR_MAX + 1 instead to more accurately represent what this is (max value of an unsigned byte -- our opcode -- +1 to include all of them), rather than the magic number that is 256.