plugins: Do not require a "type" subfolder hierarchy

The folder structure was introduced to organize the
plugins and permit more efficient loading during the
startup but the gains are slight and the requirement
is awkward to describe and easy to forget in practice.

Remove that requirement and load any compatible binary
plugin in the plugin folder. This also allows extra
flexibility to organize the plugins in categories,
for example adding an "external" folder for plugins
external to the project, or whatever else one might
wish.

To check for library compatibility we add an extra string
signature token in the plugin that can be compared with
the expected plugin type.

The downside is that the initialization is still performed
3 times and more files need to be skipped now but in practice
this should not have a measurable performance impact
and this eliminates a class of annoying small forgetful mistakes
when manually installing files.

This is still compatible with the old requirement of having a
epan/wiretap/codecs subfolder. At most one sublevel is allowed
to minimize security risks and slowness with any random folder
hierarchies if the plugins folder setting is somehow misconfigured
or hijacked.

Ping #19389.

1 files changed, 5 insertions, 0 deletions

diff --git a/doc/release-notes.adoc b/doc/release-notes.adoc
index 01f3ae0c4f..50993af1ce 100644
--- a/doc/release-notes.adoc
+++ b/doc/release-notes.adoc
@@ -45,6 +45,11 @@ The following features are new (or have been significantly updated) since versio
 
   ** Fields with value strings now support regular expression matching.
 
+* Binary plugins can be placed on the root of the versioned personal plugins
+  folder or any subfolder one level below that. The global and personal
+  binary plugins folder no longer have to obey to any particular hierarchical
+  structure.
+
 //=== Removed Features and Support
 
 // === Removed Dissectors