MAVFtp issues, especially for components like gimbals etc

I'd like to report a couple of issues I experience with MAVFtp for components in particular, for MisssionPlanner 1.3.79 (the component is a STorM32 gimbal). These issues are largely present since a while, e.g., had been there also in 1.3.77.

1. MP always shows a `@SYS` folder, even though the component only has a '\' directory. What actually appears to happen is that MP is specifically asking for a `@SYS` directory. If the component responses with a NAck with kErrFileNotFound (= 10) MP behaves non-gracefully in that it tries to get it for a couple few seconds. The behavior is more gracefull if the component responses as if it did not have such a directory but would be empty, i.e., with kErrEOF (= 6) in the NAck.
IMHO, MP should not dare to ask for a `@SYS` folder for non-ArduPilot components. If it still for some reason wants to do it, it at least should properly react to a NAck with kErrFileNotFound, i.e., terminate the request immediately. It neither case it should show that false directory, but only those it got from the component.

2. The fluke `@SYS` folder is always selected first, and not the top available directory. This may be quite confusing to users as one moves to the MAVFtp page but doesn't see any files.
This would be naturally resolved by resolving point (1), but suggests that the code for the choice of which folder to show as default may need to be reworked.

3. The MAVFtp option is sometimes not immediately shown in the side bar menu, when a component had been selected. I then need to change between pages like Data, Setup, Config a couple times to eventually find the MAVFtp option being shown. Note that this is not because the capabilities would not yet have been obtained from the component. This can happen even long after that.

4. MP appears to send out a ftp message with opcode ResetSessions early on after connection, and does this with broadcast tagets. This doesn't make sense as the components may become online at their own pace, and not in sync with MP.
IMHO, MP should send this initializing ResetSessions per component, e.g. when a component has been discovered and the capabilities for that component were obtained.

5. MP appears to not respect or react properly to kErrFileNotFound in general, i.e., also for the ArduPilot component. For instance, if I make it that its request for param MAVFtp, i.e., the file `@PARAMxxx` is NAcked with kErrFileNotFound, then it continues with its try loop for a half dozen seconds before it concludes that this file is not existing and goes on.

Many thx,
Olli

Start by locating Mission Planner's MAVFtp handling and the component-selection/sidebar entry points, then reproduce the reported behavior with a non-ArduPilot component such as the STorM32 gimbal. Trace directory requests, kErrFileNotFound handling, default-folder selection, sidebar visibility, and ResetSessions broadcasts. Done means the false @SYS folder and delays are removed, the correct folder is selected, MAVFtp appears reliably, and ResetSessions is sent per component.

Written by the indexing model from the issue text.