Allow plugins to define custom operations that they use scripts for

[javanna]

Plugins can now define multiple operations/contexts that they use scripts for. Fine-grained settings can then be used to enable/disable scripts based on each single registered context.

Also added a new generic category called plugins, which will be used as a default when the context is not specified. This allows us to restore backwards compatibility for plugins on ScriptService by restoring the old methods that don't require the script context and making them internally use the plugins context, as they can only be called from plugins.

Closes #10347

[javanna]

@uboness assigning this to you for review

[uboness]

@javanna (don't kill me) thinking out load.. going back to the previous enum... would it be better to change that enum to an interface, such that the contract ScriptService's methods will be clearer/"safer".. yet the context will still be based on an opaque string. Something like:

public interface ScriptContext {

    enum Std implements ScriptContext {
        MAPPING() {
            public String key() {
                return "mapping";
            }
        },
        SEARCH() {
            public String key() {
                return "search";
            }
        },
        UPDATE() {
            public String key() {
                return "update";
            }
        },
        AGGS() {
            public String key() {
                return "aggs";
            }
        };
    }

    String key();

    class Plugin implements ScriptContext {

        private String key;

        public Plugin(String pluginName, String context) {
            this.key = pluginName + "_" + context;
        }

        public String key() {
            return key;
        }
    }
}

the Plugin class is there just to promote plugins to implement the context in a consistent manner. (also, not sure if it will, but we open up the option for the context to hold more info in the future, without breaking the contract of the service methods)

[javanna]

@uboness makes sense to me, just pushed a new commit.

[uboness]

why not put this under Standard and deprecate it as an option?

[javanna]

will do

[uboness]

left a couple of comments

[javanna]

Pushed another commit. Wondering: shall we restrict ScriptModule#registerScriptContext(ScriptContext) to ScriptModule#registerScriptContext(ScriptContext.Plugin) and make ScriptContext.Plugin final? That would allow us to actually enforce conventions on context keys etc. rather than only semi-enforcing them. Would that be too restrictive? Can you think of cases where implementing ScriptContext directly would be useful over using Plugin?

[uboness]

I like it... hmm... I can't think of any scenario where you'd want to register custom contexts outside of a plugin. outside of a plugin is only within the core codebase and for that we can always extend the std enum. It's easier to start restrictive and open it up if we find the need to.. rather than open it up now and later try to restrict it. So I'd say go for it...

[javanna]

pushed another commit, restricted the custom script context to ScriptContext.Plugin instances only. We still rely on plugins providing the right info, there can still be interaction between different plugins (think of a plugin registering context plugin1_test and plugin2 using it), but I think this as far as we can take it (at least there's a single way to plug in custom contexts providing plugin name and operation).

Are we happy about using the _ operator between plugin name and operation. That will need to be used as part of fine-grained settings e.g. script.engine.groovy.inline.plugin1_feature1: on . I think we could potentially replace _ with . too, shouldn't hurt but maybe more confusing? Thoughts @clintongormley ?

[uboness]

pushed another commit, restricted the custom script context to ScriptContext.Plugin instances only. We still rely on plugins providing the right info, there can still be interaction between different plugins (think of a plugin registering context plugin1_test and plugin2 using it), but I think this as far as we can take it (at least there's a single way to plug in custom contexts providing plugin name and operation).

agreed

Are we happy about using the _ operator

yea... I chose this one as I wasn't sure how it'd effect 1) the parsing of the settings, 2) would confuse when reading the settings as . is used to separate other elements there.

[javanna]

cool @uboness can you go over it one last time please? should be ready

[uboness]

shall we add a NOTE: here about custom plugin contexts?

[javanna]

Plugins are briefly mentioned a few lines above:

Plugins can also define custom operations that they use scripts for instead of using the generic plugin category. Those operations can be referred to in the following form: $pluginName_$operation.

That said I haven't explained how plugins can do it, but we don't really have reference for plugins so maybe this is enough?

[clintongormley]

Are we happy about using the _ operator
yea... I chose this one as I wasn't sure how it'd effect 1) the parsing of the settings, 2) would confuse when reading the settings as . is used to separate other elements there.

Agreed. I'm happy with _

[uboness]

left a small comment on docs (not sure if we want to mention plugin as we don't really mention plugins anywhere else AFAIK)... other than that LGTM

[javanna]

ping @dadoonet you might want to update plugins to use the plugin category, or even define their own script context.