Add support for access code read operations

[piotrantosik]

• Implemented commands and message structures for reading access codes, attributes, and configurations.
• Added IPanelAccessCodeService with methods for managing access codes.
• Updated navigation and UI to support access codes page.
• Enhanced binary serialization sorting for inheritance depth.
• Extended session state to track access code data.

[piotrantosik]

@BrianHumlicek PR is ready. For now, it's a separate subpage, but I was thinking about adding it as a separate tab in Panel Configuration.
Successfully fetched username. Users are being loaded asynchronously to speed up the reading process.

[BrianHumlicek]

I'm on the fence about putting it under panel configuration because DSC seems to treat this data differently than the panel config. Also, this is something that a user or manager would actually change or use regularly, whereas the panel config really is installer only configuration that should rarely need modification.

Also, I'm thinking about the page and related data being referred to as "AccessCodes". This is the panel user list, though I could see it as the PanelAccessCode list and the user name is more of a descriptive label. I'm not sure what makes more sense from a usability standpoint and a technical implementation view.

Looking at the implementation, many of the messages are defined as byte[] message stubs and it doesn't look like they were ever revisited for formal definition. The service is parsing message data vs. defining it in the message and using the serializer. Also things like the LabelType in the NotificationLabelMessage are inlined vs. a formal enum. Speaking of which, I see you figured out that 0xD9 is the user label, I am thinking of creating an enum with D1,D3, and D9, but I suspect that other information is bitmapped in there. Do you have any more information on what that byte does?

Brian

[piotrantosik]

Correct, I missed verifying the response classes after testing/debugging. I've updated them, renamed 'access codes' to 'panel users', and introduced LabelType enum

I'm still testing a few things; I might be able to handle all users with a single request.

[piotrantosik]

@BrianHumlicek PR is ready. I’ve applied all fixes - please take a look again when you have a moment.

[BrianHumlicek]

I've been reviewing and testing. I found that the messages support multiple users in the response, so for instance I was able to read all 72 access codes in a single request. I'm working on updating the message definitions to reflect this. Additionally, I want to see if I can figure out the write.

I'm definitely looking at it. It's a big change with a lot of parts. I'll do my best to push a branch so you can follow along.

Brian

[BrianHumlicek]

I have pushed changes that allow writing of the user parameters except the label. I'm having trouble figuring out the message format. Its none of the usual suspects. If anyone has any ideas or can figure it out, that's the last piece before I can push this to master.

[piotrantosik]

I'll try to play around with the write format in a few days once I have a bit more breathing room. Busy week, but I'm on it! :)

[BrianHumlicek]

I believe the current branch has the access code label message defined as a byte[] followed by a 14 char utf encoded string. I did this as I am fairly certain that a valid message will have those string bytes at the end and it allows me to try combinations of bytes for what precedes it.

I have tried everything I can think of that would be common. I'm am beginning to wonder if it uses some kind of descriptor byte like the section read messages. It's kinda frustrating. I need some new reference material.

Brian