Followup to the above review comment: #10478 (review)

Retracting the requesting changes review - while the question of dropping the device index remains (see below), the change in this PR is a step in the right direction regardless.

Indeed strictly speaking I think there are two distinct scenarios in the model with distinct requirements: One to drop all files and index ID for a device, in cases where the folder stays shared with the device but needs a index/file reset. And another to do that plus drop the device index on unshare. Otherwise we keep that device index forever in the folder device table (unless that's intentional?). We could also simplify code and always drop all information/use folderDB.DropDevice even on a index ID reset when the device isn't unshared - just re-inserts the device index with a bumped integer.

@imsodin I thought about this too when climbing up the "ladder" to hunt down the bug. I didn't consider the bug to be that folderDB.DropDevice is used when unsharing, because the problem is older than per-folder databases, and when one big SQLite database was used I think DropAllFiles was correct.

You likely mean this change, right? cf1cf85
Looks like the behaviour was the same before it, i.e. it also didn't remove the index IDs on DropAllFiles. Anyway, doesn't really matter when it changed, it clearly isn't right/needs fixing which you do here.

On my wider topic on removing the device idx - mostly FYI in case anyone is interested and to sort my thoughts, not relevant to merging this PR: In v1 the DB device idx was global we never dropped: Naturally not when dropping a index ID or unsharing a folder (as it wasn't folder scoped), but also not even if a device was entirely removed. In v2 before the folder split the device index was also global, and never removed: The method DropDevice existed, but was not used. And it still exists and isn't used now, and newer was. So a little opportunity for cleanup exists there (though looking at the cleanup/config change logic in model.go is headache inducing (I may say that, a lot of that is mine 🙃 )) :)

You likely mean this change, right? cf1cf85

@imsodin Yes, that's the change I was talking about.

Looks like the behaviour was the same before it, i.e. it also didn't remove the index IDs on DropAllFiles.

Indeed. I pointed that out above:

the problem is older than per-folder databases

Argh right. Also the sequence is tracked together with the index ID in the DB, and afaik in the (hypothetical) scenario where the remote announces an index ID and non-zero sequence but then still sends an index (not update), we'd want to keep the index ID but set the sequence to zero. Something like this should afaik fix the the bug and deal with the sequence: #10480 ?