Replace / expand prefix to allow using a generic function for rewriting paths

[WesleyAC]

I use rust-embed for my webservers, and am a great advocate of it. However, it seems that implementing the cachebusting filename pattern is somewhat difficult. While the SHA256 hash is exposed via the Metadata struct, using this in a filename (rather than a query parameter, for instance) is difficult, as the hash needs to be removed from the path, checked, etc.

My proposal to make this easier is to make a rename attribute similar to the existing prefix attribute, but instead of taking a string, taking the name of a function fn(path: &str, metadata: &Metadata) -> String that would be applied to all path names at compile time. This would allow people to write a custom function to rewrite path names to include part of the SHA256 hash or similar.

I also propose adding to the RustEmbed trait a function to get the rewritten name of a file, given the name of a existing file. While in some cases the rewrite function could be called directly to find this, in cases that rely on file metadata, this isn't possible, and providing it as part of the trait would be useful. This would be used to generate the filenames that are embedded into HTML templates and such.

A feature like this would allow people to do everything prefix currently does as well as more complex things (cachebusting filenames probably being the most useful). I think keeping prefix around makes sense from the perspective of minimizing churn, but probably a error should be raised if someone attempts to use both prefix and rename, telling them to simply do the prefixing step in the rename function — that would keep things simple, by ensuring the two features never interact.

[WesleyAC]

One thing I haven't considered too much here is the implementation of the debug mode — doing something like this would require watching the directory for changes to recalculate the names, since there's no way to reverse the rename function (unlike prefix). That's potentially a significant amount of complexity, but I do think it would be worthwhile.

[pyrossh]

Interesting Idea. Thats how it is generally handled by web bundlers like webpack/rollup in meta-frameworks when serving immutable assets. They would compile the assets to include the hash in the name. So it should work out of the box for those tools. For other cases where it needs to be manually done this feature would be useful.

Does it make sense to make this a setting or a feature so that it can be done automatically since many use cases involves serving web assets. I haven't seen passing a function reference as an attribute to custom derive before. Might need to test it out.
For the 2nd point I don't know why you would want to do it in debug mode unless you want to cache there as well.

The easiest solution I can think of is adding another key in the BTreeMap with the format $path/$filename.$hash.$ext pointing to the file.