feat!: Use entrypoints and RendererProvider for more reliable Renderer registry

[sylv256]

Problem

Because Renderer can be rendered at any point before or during Minecraft's initialization until it is used, problems arise when it's necessary to use it early. For example, in order to disable Indigo, FRAPI implementations need to add a custom field to their fabric.mod.json. Renderers should not need to add a field to their FMJ just to disable Indigo, let alone any other Renderer. Also, mods extending FRAPI such as Conduit need a defined point in time during and after which Renderer is ready to use. All of this introduces inconsistent behavior and quickly becomes a headache. See #3109 for more details.

Solution

This Pull Request overhauls and adds new concepts to FRAPI's Renderer registration.

RendererProvider

interface RendererProvider {
    static String getModId() { // Gets or finds the mod ID RendererProvider for the renderer that will be loaded
        // ...
    }

    @ApiStatus.OverrideOnly
    Renderer getRenderer(); // Gets or instantiates the Renderer implementation

    @ApiStatus.OverrideOnly
    default Collection<String> getOverrides() { // Renderers that this renderer overrides (any listed will not load)
        return List.of("fabric-renderer-indigo");
    }
}

Instead of manually calling Renderer#register, renderers are now registered with an entrypoint fabric-renderer-api-v1:renderer_provider set to the implementation of RendererProvider. This lets mods get basic information about the renderer that will be loaded at any point during the game's execution as they can be loaded immediately, and this is especially useful for Mixin Config Plugins.

The entrypoints section will look as follows:

"entrypoints": {
  "fabric-renderer-api-v1:renderer_provider": [
    "tiny.potato.renderer.impl.RendererProviderImpl"
  ]
}

and the class:

public final class RendererProviderImpl implements RendererProvider {
    private static Renderer renderer;

    @Override
    public Renderer getRenderer() {
        if (renderer == null) {
            renderer = new RendererImpl();
        }

        return renderer;
    }
}

Justification

Sometimes, mods will want to use Renderer right away, and this is where the issues with the prior system really reveal themselves. Previously, if a mod wanted Renderer, they would have to either use Renderer#get and hope it's already registered, or they would Mixin into Renderer#register to ensure that Renderer has been registered before using it.

Conduit is a library built to create and implement extensions for FRAPI. In order for Conduit's extensions, implementations, and users to use FRAPI and Conduit effectively, it must be possible to get the Renderer instance early. Some operations are best done at mod initialization after Renderer has been initialized, so having a lazily initialized Renderer to ensure code that requires Renderer does not use it before it is registered is powerful.

Tests & Integrity

I've added two checks: one in FRAPI itself to ensure a renderer is loaded, and a unit test to ensure the override ordering is correct. If either of these conditions fail, an exception is thrown.

Additional Information

Proof that it works

Fixes #3109

[sylv256]

Setting to draft as changes were requested

[sylv256]

???

[Juuxel]

The changes look fine assuming this is something that renderer impls and consumers want (I'm not a huge expert in this area), just some minor comments from me.

[modmuss50]

Great 👍

[modmuss50]

This is ready to merge, I can either do it now before the rendering API has been ported to the latest snapshot or after? Im not sure what is better.

[sylv256]

This is ready to merge, I can either do it now before the rendering API has been ported to the latest snapshot or after? Im not sure what is better.

Go ahead and merge this. The port is likely going to take a while, and I don't think this will interfere much.