Use provided SFTP paths if enumeration fails

[mavit]

In #1610 (comment), Andy Holmes wrote:

So in fact GSConnect generally ignores the path sent by the Android device and tries to list the directories itself.

This could be fixed by either reverting that patch, or possibly falling back to the advertised paths if the listing fails. Patches for either would be okay by me.

This is that patch, to fall back to the advertised paths.

[ferdnyc]

@mavit

I suspect the change in #1801 might actually be more on track here — previously, GSConnect always tried to mount sftp://user:password@a.n.i.p:port/ and get a list of the contents. But since the android app switched over to MANAGE_EXTERNAL_PERMISSIONS, the packet.body.path won't always be / (previously, it always was), and more importantly it appears / won't be accessible to us from the SFTP server — it publishes the filesystem using its on-device path, now.

So, if packet.body.path is something other than /, we should use that in the initial connection and stop trying to access the root of the SFTP filesystem.

The impression I get is that, even if multiple shared locations are configured (which doesn't appear to be possible on Android 11+ anymore, the preferences for doing that are totally gone in the Android app)... but even if multiple locations are configured, they're meant to be accessed directly and separately, not by mounting and listing /. The KDEConnect Android code makes me strongly suspect that's not supported (and maybe never really was).

[mavit]

This versus #1801 is swings and roundabouts, I think. If we mount sftp://${host}:${packet.body.port}/${packet.body.path}/ then then it'll be nicely browsable from Nautilus, but we'll loose access to any external storage connected to the Android device.

I'd be tempted to merge this for now (since I don't think it has any drawbacks compared to what we currently have). When someone finds time, they can look at reworking the code to mount each item in multiPaths.