[FileDatabase] Optimize addin scanning

[Therzok]

The format of the addin cache data is something like below: Users_therzok_Work_md_monodevelop_main_build_AddIns_MonoDevelop.AzureFunctions_azure-functions-cli-66a932fb_nb_abf27ece.data

That means that the code which is removed was looking for something that would match:

_sha*.data Only 1 item matches that (the direct query), and if the direct query did not match, it means scanning the whole folder for another file which matches the pattern is useless. Reduces AddinDatabase.Update for full VSMac from 1.95s to 0.72s, that's 1.23 spent just doing IO via Directory.GetFiles.

[Therzok]

The reason this is problematic is that there are folders in the recursive scan which don't match any addin, i.e. ../AddIns, ../AddIns/AspNet/CodeTemplates, and every folder which doesn't match an addin will trigger a full database cache iteration.

[Therzok]

@slluis so, we have to define directories to exclude? The main problem with the code is that we're probing for addin cache data for directories which are not addins.

[slluis]

No, we have to make the file database more efficient in detecting that data doesn't exist for a path. I have an idea about how to do it.

[slluis]

It should do the following: 1) Check if data file exists:

• If it exists, try to open it. If it fails, go to 2)
• If it doesn't exist, return not found. 2) look for file_(n+1).data, go to 1)

Besides that, it needs a strategy to delete old unused files, and avoid unbounded directory growth. But this may be fixed separately.

[Therzok]

Updated.