* Added updated German strings and added hybrid toolkit to locproject.json
* updates to XLF files
* more resources added to locproject
* restored out localizations
* fixes to dacpac and admin-tool
* fixes to dacpac and import
* updates to english XLFs (more up to date)
* Adding a null check to prevent infinite next button loading on account selection page.
* Remove a useless validation in migration cutover page
* Fixed some component formatting in source selection page
* Completely updated target selection page UX according to latest figma mockup
* Adding confirmation for migration cutover and cancel
* migration vbump
* azdata vbump in migration extension
* letting users do a cutover with unrestored files
* Fixing some localized strings
* Adding readme file for migration extension.
* Adding a static link for readme gif
* added sql mi typing, localized strings, some null checks
* casting target instance as sql mi
* Added Azure Log Analytics resource for generating AAD Token.
* Fixed AzureResource
* Removed debug code from connectionManagementService
* Moved AzureLogAnalytics from AzureResource enum in azdata.d.ts to azdata.proposed.d.ts. Added azureLogAnalyticsResource to all azureSettings in providerSettings.ts
* Updated endpoint for generating AAD Token for LogAnalytics for UsGov, UsNat, and China
* Removed azureMonitor resource from germanyCloud in providerSettings
* Added missing resources to AzureResource in account interfaces.
* Added comment linking enums for AzureResource
This change introduces new boolean flag for `addToProject`, `addScriptItem` and `addFolderItem` APIs that allows to skip files/folders if they are already included in the project file. Original behavior was to throw an error if duplicate entry is encountered, so I kept that as a default (new flag is not set).
I started by fixing the original behavior, as it was not always working as expected. In our extension that relies on `addToProject` API we've hit an issue where duplicate items were added and no errors were thrown. There was a test for this scenario, but unfortunately the test had few bugs in it as well, so I addressed that first. First issue with the test code was missing `await` on the `testUtils.shouldThrowSpecificError` calls, so test was not actually testing anything. After adding missing keywords, I hit an issue where exception was not thrown, but this turned out to be different issue, compared to what we were hitting. In the test code, it was using the very first folder from the generate list of test entires. This folder wass actually the root of the project (where sqlproj file is located), and `addToProject` API had a special case to ignore the root. This means neither first call nor second call was actually adding anything to the project and no errors were produced. I fixed this problem by using next available folder in the generated files list.
After addressing the test code I could not reproduce the issue that we were seeing with duplicate entires being added, everything was working as expected and errors were thrown. I started adding more tests that better resemble our production scenario - add files in subfolders, add files to existing project, rather than a new one. Finally I was able to reproduce the problem in tests when adding a file in a subfolder to an existing project. After investigation this turned out to be an issue with mismatch in how `relativePath` is maintained within the `FileProjectEntry`. When loading an existing project, `relativePath` is populated based on the value of the `Include` attribute of the `Build` item. This attribute is normalized to Windows-style path, using `\`, so for nested file you will have `folder\file.sql`. When adding new item to the project, one could pass either Windows or Unix-style path (`folder/file.sql`), so the path comparison between loaded Windows-style path and newly added Unix-style path was failing, resulting in them being treated as different items. In fact, `addToProject` API that we were using was relying on `Uri` helpers to extract relative path, thus the path was forced to be Unix-style and path was never the same as the loaded one. After this discovery I added a dedicated test to validate the round-trip of the `relativePath` for serialized and desirialized project file.
In order to address this problem, I updated the factory method `createFileProjectEntry` to always run `utils.convertSlashesForSqlProj` on the relative path to ensure we have Windows-style path stored in there. I also optimized the helper code slightly to not do split/join, if there are no split points in the input string, which should eliminate unnecessary array instantiation. It is worth mentioning that I had to normalize the input relative paths in the `addScriptItem` and `addFolderItem` APIs, because there is no guarantee that they will be Windows-style when we try to compare them to `relativePath` of the existing project items.
Finally I was able to add a simply flag and update the condition to return existing record, if duplicates were allowed. I also updated typings file for the extension and added tests to cover this scenario.
