Handle invalid channel replies

Description

This MR solves #2 (closed) that describes how invalid channels make the ESP32 reboot due to unallocated memory access violations.
The mpod replies with unset values, so Varbind::getValue was doing memory access violation.
This is now handled by checking the payload size before trying to read it.

How Has This Been Tested?

This was tested by requesting status and sending commands to an invalid channel 199 on the test crate.

Relevant Documents (optional)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Docs (changes to the documentation)
• Style (formatting changes only, no code changes)
• Refactor (refactoring code with no functionality changes)
• Test (additional or refactored tests)
• Chore (non-code changes, e.g. comments, readme, grammar, etc...)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I added tests where appropriate.

mpod.cpp

@@ -142,6 +142,11 @@ bool MPOD::message(const SNMP::Message *message) {
         // that far.
         const char *channel = strrchr(varbind->getName(), '.') + 1;
         _channel = atoi(channel);
+
+        // MPOD SNMP channel 0 does not exist (starts from 1; U0 is 1).
+        // Mark the channel as 0 if invalid data was received.
+        // This can be used later to validate a sent request.
+        _channel = found ? _channel : 0;
     }
     // Return true if nodes found, that means this is a valid response from MPOD
     return found;