Replace path canonicalize with our own version.

[andriyDev]

Objective

• Renaming a file does not send a rename event to the asset system, meaning that renamed files are not detected!
• In Make asset watcher work when path contains "../" #18023 we canonicalized the file path to work with asset folder paths that were relative. However canonicalize only works if the path actually exists! During a rename the old path no longer exists, so canonicalize fails and so we just silently continue.

Solution

• Instead of using canonicalize, we write our own implementation using the std::path::absolute which uses the environment's current directory to create an absolute path (but doesn't collapse ..), and then use our normalize_path to collapse .. into a "canonical path".
  • The advantage is that this doesn't interact with the filesystem at all, so any path will be able to be resolved - including the file that was renamed (even thought that file path no longer exists).
  • The disadvantage is that this no longer resolves symbolic links - I don't see this as a big problem since I doubt our behavior makes sense in that case (a sym link will probably just send us out of the assets dir and give us a file path we won't know how to deal with).

Testing

• I ran the asset_processing example. I made sure that renaming an asset or directory resulted in a rename event.
• I also tried changing the asset_processing example to use a relative path like Asset watcher fails to update assets when path contains "../" #18022. Changes were correctly detected!
• I also checked that the embedded_watcher feature still works by making sure that one of our embedded shaders were hot-reloaded.

[viridia]

See #10511

[andriyDev]

@viridia While I agree with the goal that we should stop using Path in AssetPath, I still think this PR is a step in the right direction - we should stop depending on the behavior that we read the filesystem to resolve paths. It should basically just be a fancy concat.

[viridia]

Doing a basic path resolution algorithm - one that includes support resolving for /./ and /../ - isn't that difficult. In fact if you look at the implementation of Path and subtract out all the crazy windows drive letter stuff, it's not that complicated. This is something I had originally planned to tackle a couple years ago and then got bogged down in the distinction between str and OSString.

My point is that it may be easier to just go straight there than doing this intermediate step. Although perhaps not in time for the RC.

[andriyDev]

We already have a function for resolving /./ and /../ called normalize_path: which we use in this PR! The only thing that isn't handled is resolving the absolute path, which is effectively just a concat of the pwd and the provided path. Seeing as how this is specific to the file asset watcher, I think we should keep this the way it is - the conversion to whatever str/OsString we use in an AssetPath should come after this anyway.

So I'm not exactly sure that we would ever want/need to re-implement absolute for the AssetPath.

[ChristopherBiscardi]

about as straightforward as dealing with paths can be