LOG browser download - Incorrect Mavlink implementation ?

#### Issue details
We have come across a possible bug in mission planner for Windows whilst downloading logs from our custom autopilot.

As per MAVLINK documents, log data should contain a field named .count, which is the amount of data included in the log packet [https://mavlink.io/en/messages/common.html#LOG_DATA](url), and a count of 0 signifies the final log item. However, it seems mission planner on windows may be using a count of anything less than the 90 limit to signify the end of the log, hence resulting in the download ceasing after the first item in our case.

This was tested by us changing our code to declare a count of 90 for each log data, which resulted in a successful entire log download, when reverting the code to declare the correct count for each log data packet payload (somewhere between 20-90), mission planner stated the download is complete after the first log item is sent - resulting in a saved log file with 1 line.

Problem does not persist on a Linux installs of mission planner and apm planner, nor does it occur on QGroundControl on windows.

An extra note: the logs we create onboard our autopilot are stored, encoded, mavlink messages, if this causes any problems.

#### Version
1.3.77 - 1.3.8110.38294 (windows)

#### Platform
Mission planner interfacing with a custom autopilot using mavlink c library v2.

#### Airframe type
N/A - autopilot is currently set to report mavlink vehicle type ground rover

#### Hardware type
Custom made, tested over multiple stm32 boards

#### Logs
The TLog shows multiple LOG_DATA mavlink messages were received [https://pastebin.com/cGUrXiWG](url)
And the created LOG is a single line [https://pastebin.com/gz5q0ag9](url)

Start by reproducing the Windows log download with LOG_DATA packets whose count is between 20 and 90, using the linked TLog and output log as evidence. Trace the Mission Planner log-download handling and compare its completion behavior with Linux and QGroundControl; done means the complete encoded log is saved without treating a nonzero count below 90 as final.

Written by the indexing model from the issue text.