Load a plugin by alias name.

[andsel]

If the plugin name is an alias and no other plugin exists with same name then load the alised one

Release notes

Introduce the concept of aliased plugin, to let a plugin be renamed easily

What does this PR do?

An alias for a plugin is a just a rename of an existing plugin, in this way the alias can be used in pipeline configuration. If later a real plugin with same name of the alias is released then that plugin takes precedence over the alias name.
Suppose we a plugin filter named teleport and we also alias it as teleport_over_fiber, the teleport_over_fiber alias can be used in interchangeable way as teleport with same parameters and behavior. In a future when a real plugin that leverage fiber transmission for teleport a plugin teleport_over_fiber name is effectively released, this real plugin takes precedence to over the alias.

The changes to logstash-plugin tool used to manage the installation, listing and removal of aliased plugin is handled by the PR #12821

Why is it important/What is the impact to the user?

It lets the user to star using today plugins names that will be released as independent plugin in near future.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files (and/or docker env variables)
• I have added tests that prove my fix is effective or that my feature works

Author's Checklist

• try a local run

How to test this PR locally

Use an alias in a pipeline config, for example:

input {
  elastic_agent { # beats alias
     port => 5044
   }
}
output { stdout {} }

check that it runs correctly with bin/logstash -f pipeline.conf

Related issues

Use cases

Screenshots

Logs

[andsel]

Note for review.
Here I had the doubt to use streams, introducing a support class:

private static final class NameAndClass<T> {
    final String name;
    final Class<T> clazz;

    NameAndClass(String name, Class<T> clazz) {
        this.name = name;
        this.clazz = clazz;
    }

    @SuppressWarnings("unchecked")
    static <T> NameAndClass<T> fromEntry(Map.Entry<String, T> e) {
        return new NameAndClass<T>(e.getKey(), (Class<T>) e.getValue());
    }

    @SuppressWarnings("unchecked")
    public <T> NameAndClass<T> withName(String newName) {
        return new NameAndClass<T>(newName, (Class<T>) clazz);
    }
}


final Map<String, Class<T>> aliasedToAdd = pluginCache.entrySet().stream()
        .map(NameAndClass::fromEntry)
        .filter(e -> isAliased(e.name))
        .map(n -> n.withName(aliasFromOriginal(n.name)))
        .filter(n -> !pluginCache.containsKey(n.name))
        .collect(Collectors.<NameAndClass, String, Class<T>>toMap(n -> n.name, n -> n.clazz));

But we have to create a support class only for this and has a lot of object creation due to stream

[yaauie]

I think I've got one last set of changes to suggest, but otherwise LGTM.

I'd like to get this merged/backported and chase down the unrelated DLQ test failures separately.

[yaauie]

LGTM 👍

Let's merge & backport as soon as the ruby tests pass CI.

[yaauie]

🤦🏼

Suggested change

}