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.

[pinges]

I think you should get rid of the --strict-plugin-registration-enabled
When I'm specifying --plugins on the CL and one of the plugins is not found I would expect that besu does not start

[fab-10]

Looks good and it is a nice feature, just some minor suggestions

[macfarla]

couple of comments. Also if the plugin AT failure turns out to be because of the changes in the PR, would be good to make that easier to find (error handling?)

[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.

[jframe]

This doesn't say what kind of control is being added. Maybe something like Allow users to specify which plugins are registered