Embed default resources in Servo applications using a servo-default-resources crate

[jschwe]

This PR considers the following constraints:

• Resources must be available when building servo via a published crates.io package (i.e. no ../../../resources/<file> file references).
• Minimal setup when writing tests (nextest spawns each test in its own process, so we don't want to explicitly initialize the resource handler for every #[test] fn)
• Use local resources when developing locally
• Support loading the resources from a proper resource directory if the embedder wishes so, including via a custom mechanism, not necessarily as files

(File) Resources that are only accessed from servoshell are out of scope of this PR, since it mainly focusses on unblocking publishing libservo to crates.io.

Baking the resources into the binary by default simplifies the setup a lot. We already supported that before, but only for testing purposes and explicitly not for production builds.

Using inventory adds a simple way for the embedder to replace the default baked in resources, while also keeping the test usage of baked in resources simple.

rippy.png is also referenced from image_cache - We simply duplicate it, since the image is small, to avoid adding unnecessarily complex solutions like adding a dedicated crate.

Testing: Covered by existing tests. mach try full
Fixes: Part of #43145

[jschwe]

So, there is a bit of a tricky bit here:

• We have the named resources (now placed in embedder-traits)
• We have a limited number of FS based resources, we read from the filesystem in the "resource dir" (default user-agent-js and files served by the resource protocol handler in servoshell)

I'm tending towards splitting resource protocol handler related things into a separate folder in our repository, and am considering having two different resource readers. One in embedder-traits for the named resources. And the one in servoshell, is "embedder-specific" and would handle the resource protocol. Perhaps a helpful abstraction like FsResourceReader could be made, to reduce boilerplate, but some embedders (ohos / android), might prefer to not read resources (resource protocol resources) from an actual file, but use platform specific APIs to read data from the app-bundle.

The user-agent-js file could probably be changed to be a named resource too.

I'm also thinking about how to search for the resources directory, since "next to the binary" doesn't work well for the standard in-tree approach, and probably we need to have code to support both developer experience for in-tree builds, while also handling production builds appropriatly.

[webbeef]

The resource:// protocol handler already reads only from resources/resource_protocol so that should be easy to move somewhere else.

[mrobinson]

Perhaps we should just remove support for the "user-agent-js" directory. This seems like something that should be handled by the embedder using the UserContentManager API.

[jschwe]

I'm also thinking about how to search for the resources directory, since "next to the binary" doesn't work well for the standard in-tree approach, and probably we need to have code to support both developer experience for in-tree builds, while also handling production builds appropriatly.

I pushed a proposal / draft for this, which uses mach (well an environment variable really) to determine if we are a developer build or not and use the in-tree resources. When packaging we package the named resources into the global resource directory, which servoshell will search for. I'm not really happy, but I'm also been going a bit in circles and don't have a great idea otherwise on how to load the resources from the embedder-traits (supporting both crates.io builds and local mach builds) when developing and from somewhere else when shipping a packaged servo.

[jschwe]

I pushed a different proposal (loosely based on a suggestion of @mrobinson ) baking in resources on most platforms by default (but optional, as feature flag. To make it convenient to override, this uses the inventory crate which internally is basically like attribute(__constructor__) in C/C++ but with a safe API.
Embedders can disable the baked-in-resources default feature and use inventory::submit!() to submit a ResourceReader implementation.

[mrobinson]

Looks pretty good to me! I have a few comments and one request: Let's move default-resources out of shared as that is meant for the *-traits and *-api crates. It will likely be eliminated sometime in the future.

[mrobinson]

Is this necessary just so that this doesn't show up in tools like machete?

[jschwe]

It's necessary to make sure rust links the crate (and hence the resource reader is registered). I think extern crate syntax would also work. I'll check machete out and see if it warns about this. I see there is a way to ignore false positives, so probably we can do something. (I'm wondering if machete is being used by rust-rover under the hood)/

[jschwe]

machete doesn't complain about these usages. But we still need this, otherwise the default resources crate will not be linked (declaring the dependency in Cargo.toml is not enough, which was a bit surprising to me, but I guess makes sense).

[jschwe]

@mrobinson I believe I have addressed all comments. Let me know if this PR is good to go.

[mrobinson]

In many ways this seems simpler than what we had before which is really nice.