Make AssetPath::get_full_extension work for non-UTF-8 file names.

[yrns]

Objective

The expectation is that extensions will be UTF-8 in order to match asset loaders, but if the file name itself is not, it should still work. This fixes that.

Solution

This works on bytes and returns &str instead of allocating a String. The changes outside of the function itself relate to the return type changing.

Testing

cargo test --workspace --tests

[alice-i-cecile]

I like this fix, but two small requests:

1. Please add a regression test.
2. Please add a simple migration guide.

[github-actions]

It looks like your PR is a breaking change, but you didn't provide a migration guide.

Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes.

[yrns]

1. Please add a regression test.

I'm on Linux. I'm not sure there's a way to write this in a platform-independent way. I think it works for Mac, too. I'm not sure about others.

[alice-i-cecile]

We could cfg flag the test based on the platform? @viridia or @andriyDev might have better advice.

[andriyDev]

I wonder if this change is worth making... In the future, we expect to make AssetPath just hold a String and then leave any platform specifics to AssetSources. This would result in a regression here, since users could start depending on these non-UTF-8 file names.

I think my (very weak) opinion is that we should not fix this since it's not where we want to go long term anyway? @alice-i-cecile thoughts?

As for the cfg flagging the test, I can't think of anything other than using OsString::from_encoded_bytes_unchecked and some unsafe. I think that's too much risk just for a test, so only making it work on Unix sounds fine to me.

[viridia]

I share @andriyDev's concerns. The way that I have always seen assets as working is that assets should live in a virtual, platform-neutral filesystem that is backed by one or more actual, platform-specific filesystems. Part of the job of this virtual filesystem is to completely isolate any platform differences. This means that things like windows drive letters should be meaningless in an asset path; it's only the AssetSource that knows anything about filesystem roots. It's the job of AssetSource to translate an asset path into a corresponding filesystem path, and that translation ought to include any necessary swizzling of character encodings. Either that, or asset paths should be checked to ensure that data conforms to the "least common denominator" character encoding for all platforms.