fix(ignore): encrypted GP frame should not parse commandFrame until decrypted

[Nerivec]

Another one... This is fun without a device to test/experiment with!

Should fix Koenkk/zigbee2mqtt#19405 (comment)
Since the commandID is encrypted, we can't parse the commandFrame here, as it may match a command ID with further processing (commissioning, channel request, etc) and would potentially fail based on the remaining bytes in the payload (would be garbage data anyway). So, if FULLENCR, skip the commandFrame until re-parsed decrypted in GreenPower class (GPP data & mic might still get parsed at wrong offset, but that shouldn't matter since they will be discarded/replaced after GP decryption and we know we have enough bytes to read them since they are bitmask-dependent).

---

Also, removed the GPP data & mic from the raw payload that gets parsed when commandID is not specifically parsed (so it's the actual payload). It's a bit more important now that GP has generated definition support (avoids trying to figure out what the bytes mean for new devices... when they are just duplicated metadata). With some extra tests to try to cover everything as much as possible...

zigbee-herdsman/src/zspec/zcl/buffaloZcl.ts

Lines 526 to 527 in 5bba7d6

	} else if (this.isMore()) {
	return {raw: this.buffer.subarray(this.position)};

Note: I tested the changes on the PTM216Z that uses commandFrame raw payload in converter to determine key presses. All good on that front 👍