Enhanced control over plugins registration

[Gabriel-Trintinalia]

PR description

This PR introduces improvements to the plugin registration logic in Besu, providing users with granular control over the registration of plugins. Previously, Besu attempted to register all plugins found in the plugins directory indiscriminately. With this update, users can now specify exactly which plugins should be registered, halting the application startup if any specified plugin does not exist. This feature is beneficial for environments where precise plugin configurations are necessary.

fixes #6714

CLI Options and Configuration Profiles

The new plugin registration logic introduces one CLI options:

--plugins: Specifies a comma-separated list of plugin names to be registered.

Changes

• Plugins Registration Logic: Users can now specify a list of plugins to be registered via CLI options. This list determines which plugins Besu will attempt to register. Besu validates the presence of each specified plugin in the plugins directory. If any specified plugin is not found, the application will halt, preventing startup with an incomplete set of plugins. Any plugin found in the directory that is not explicitly required will be ignored.

Examples

besu --plugins=essential-plugin,security-plugin

In this scenario, if either "essential-plugin" or "security-plugin" is not found in the specified directory, Besu will halt, signalling a configuration issue that needs resolution. Any other plugins will be ignored.

It can also be defined in TOML configuration profiles.

[Gabriel-Trintinalia]

Summary when plugins are specified:

besu --plugins=BadCLIOptionsPlugin,TestPicoCLIPlugin

[macfarla]

so if I don't specify --plugins it will have the previous behavior?

[macfarla]

also how do users know the "names" of the plugins to specify on the command line?

[Gabriel-Trintinalia]

@macfarla

so if I don't specify --plugins it will have the previous behavior?

Yes, it no plugins are specified, besu will register all plugins found in the directory.

also how do users know the "names" of the plugins to specify on the command line?

The plugin name is the name of the class that is annotated with @AutoService(BesuPlugin.class)

[macfarla]

@Gabriel-Trintinalia I see you have made more changes and the tests are passing now 💪 - can you explain about the execution strategy? How does it work and do we have to do anything differently?

[Gabriel-Trintinalia]

@Gabriel-Trintinalia I see you have made more changes and the tests are passing now 💪 - can you explain about the execution strategy? How does it work and do we have to do anything differently?

@macfarla Nothing different. I changed the implementation to make it easier to understand. The tests failed because registerPlugins are executed as the next step after ConfigOptionSearchAndRunHandler. At this stage, we have not registered any options added by plugins, and the parse failed with an unknown option error. The changes that I made to fix that are .setUnmatchedArgumentsAllowed(true) and .setUnmatchedArgumentsAllowed(false) That ensures that while we are parsing the options to create the default value provider it will not fail because of the plugin options. The second one ensures that after the plugin registration is done Besu will fail if we still have an unknown option. (expected behaviour)

I have also simplified the ConfigOptionSearchAndRunHandler. It is used to extend RunLast which at the end implements IExecutionStrategy.