SML: FastExit for binary SML parsing

[rPraml]

Description:

This improves performance for the SML parser for type 's' (SML binary smart message coding) We assume, that an SML message always starts with 0x77 / SML_SYNC and start decoding only, if the buffer starts with the sync byte. If there is a rare case, that an SML message does not start with 0x77, this improvement can be disabled with flag 32

Details:

I noticed a high load (~170) and slow FPS on the connected display (240x240 ST7789)

With this PR I tried to improve the SML parsing for binary SML data, which seems to have some room for improvement.

As far as I understand the binary parsing, there is a buffer, where each byte is added at the end of the buffer and then the buffer is shifted one byte to the left. After each byte, SML_Decode is called, which parses the the descriptor each time and checks if one line matches with the buffer. (@gemu2015 is this correct?)

In my case I have 3 Logarex LK13BE606739 meters, where each transmits ~660 bytes each second. My descriptor has ~ 60 lines, which means that SML_Decode is called ~2000 times/sec. and it will parse and check each line in the descriptor.

As far as I see, all SML messages in binary mode will start with 0x77, so I thought, it could be a good idea to implement a fast exit, and start decoding only, when the buffer starts with the sync byte, which makes the decoding a lot of faster. (0x77 occurs 23 times in my test sample of 660 bytes)

To test the improvement, I bound this to flag 32, but I want to discuss, if this could be the default. (is 0x77 really a sync byte?)

This change reduces the load from 170 to 100 and gives some extra frames on the TFT

Roland

Related issue (if applicable): fixes #

Checklist:

• [x] The pull request is done against the latest development branch
• [x] Only relevant files were touched
• [x] Only one feature/fix was added per PR and the code change compiles without warnings
• [ ] The code change is tested and works with Tasmota core ESP8266 V.2.7.6
• [x] The code change is tested and works with Tasmota core ESP32 V.3.0.0
• [x] I accept the CLA.

NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass

[gemu2015]

that seems to be a good improvement. i would suggest to make this the default und invert flag & 32 as i also assume that 0x77 is always present.

[rPraml]

I've modified the PR a bit. I still have to test this and provide a PR for documentation update...

[rPraml]

This PR is tested on an ESP32-S3 and works IMHO