fix(1059): adding explicit plugin id in PluginStatus and PluginManager

[gabrik]

This PR adds the id() method to the PluginStatus trait and allows passing it as a parameter in the PluginManager when dynamic loading or statically linking a plugin.
It exposes plugins in the admin space via their ID (see below what the ID is), and allows multiple instances of the same plugin with different configurations, essential for backends, and useful for other plugins.

Changes to configuration:

        "rest2": { // plugin id, used in admin space, to retrieve plugin config
            "__required__": true,
            "http_port": 8000,
            "__plugin__":"rest", // plugin name used in libloading
        },

Sister PRs:

• MQTT: chore: tracking zenoh fix/1059-add-plugin-id branch zenoh-plugin-mqtt#110
• DDS: chore: tracking zenoh fix/1059-add-plugin-id branch zenoh-plugin-dds#245
• ROS2 chore: tracking zenoh fix/1059-add-plugin-id branch zenoh-plugin-ros2dds#156
• WebServer chore: tracking zenoh fix/1059-add-plugin-id branch zenoh-plugin-webserver#85

Sister PRs for testing, do not need a merge.

• FS Backend chore: point to zenoh fix/1059-add-plugin-id branch zenoh-backend-filesystem#113
• RocksDB Backend chore: tracking zenoh fix/1059-add-plugin-id branch zenoh-backend-rocksdb#100
• S3 chore: tracking zenoh fix/1059-add-plugin-id branch zenoh-backend-s3#82
• Influx chore: tracking zenoh fix/1059-add-plugin-id branch zenoh-backend-influxdb#121

Closes #1059

[gabrik]

FYI: I see too many unwraps in the PluginManager implementation, indeed, they should never fail as they are calls to Vec::last after a Vec::insert but I think they should not be there anyway.

[gabrik]

Note: Lint is failing on a file that has not been touched by the PR.

[Mallets]

The PR looks good to me.
@gabrik should we wait merging it till all sister PRs are made?

[gabrik]

The PR looks good to me. @gabrik should we wait merging it till all sister PRs are made?

I'm opening the sister PRs and tagging people for review, the ones not to be merged are going to be closed.

[gabrik]

Once the sisters are approved then I'm going to merge everything.

[milyin]

This will work ok, but later some refactoring is needed I think, as the name became mostly unnecessary.
The parameters of methods should be renamed (name -> id)

[milyin]

In fact, name and pathshave the same purpose: it's a information for loader where to look for corresponding plugin DLL. Probably the name should near the paths and be optional also

[gabrik]

I think the way it is done now it is already Optional in the configuration as the user needs to specify __plugin__ to specify the name, if not specified the id is used also as name.
Thus current configurations of zenoh will continue to work.

[milyin]

I'm not sure that after this update we need this name getter at all. If plugin is dynamic, the path() getter gives us full information where this plugin came from. If it's static, name and id is the same thing.

[gabrik]

The former is true, while not the latter, the user can statically link the plugin once, but instantiate it multiple times with different IDs, thus the name will be the same but the IDs will be different