treetop.grammar: method_call; remove or extend?

**TL;DR**

The `method_call` definition in [treetop.grammar](https://github.com/elastic/logstash/blob/master/logstash-core/lib/logstash/config/grammar.treetop#L193-L200) and the respective classes in [config_ast.rb](https://github.com/elastic/logstash/blob/master/logstash-core/lib/logstash/config/config_ast.rb#L490-L495), are not very useful as they are at the moment. The question is, should this definition be removed? If not, how can we make it useful (and maybe even extendable by the user).

**Reasoning**

In [treetop.grammar](https://github.com/elastic/logstash/blob/master/logstash-core/lib/logstash/config/grammar.treetop#L193-L200) for the Logstash configuration, there is a definition for `method_call` which is supposed to enable the calling of Ruby methods in conditions.

The following Logstash config example is therefore a valid (and working) configuration:

```
input {
stdin{}
}
filter {
if to_s() {
mutate {
add_tag => [ "method_call_condition" ]
}
}
}
output {
stdout{}
}
```

The [method name part](https://github.com/elastic/logstash/blob/master/logstash-core/lib/logstash/config/grammar.treetop#L202-L204) of `method_call` is defined as [bareword](https://github.com/elastic/logstash/blob/master/logstash-core/lib/logstash/config/grammar.treetop#L70-L73), which is defined as an alphanumeric string (including the underscore character). This means, that the method name (besides of other special characters) may not include a `.` (dot) which would allow to address/use other Ruby classes nor does it allow `?` which is often used in Ruby method names (if the return value is a boolean). Therefore the `method_call` feature is limited to the actual scope, the method call is performed in. This is the actual instance of [Logstash::Pipeline](https://github.com/elastic/logstash/blob/master/logstash-core/lib/logstash/pipeline.rb). While there are some methods, which could be called (like the above used `to_s`), in my opinion there is not much left, which could be interesting/useful to call in a condition within the Logstash configuration.

A quick test revealed the following methods, which are available on `Logstash::Pipeline` (while not all are actually callable due to the limitation in character set for the method name, mentioned above):

```
methods: [:output_func, :filter_func, :outputs, :start_inputs, :inputs, :logger, :plugin_threads_info, :run, :worker_loop, :set_current_thread_inflight_batch, :start_input, :stopped?, :flush_filters_to_batch, :running?, :output_batch, :flush, :take_batch, :flush_filters, :pipeline_id, :config_str, :inflight_batches_synchronize, :start_flusher, :inputworker, :original_settings, :events_filtered, :filters?, :transition_to_stopped, :start_workers, :reporter, :filters, :thread, :configure, :safe_pipeline_worker_count, :filter_batch, :stalling_threads_info, :wait_inputs, :filter, :events_consumed, :plugin, :shutdown_flusher, :worker_threads, :inspect, :ready?, :shutdown_workers, :non_reloadable_plugins, :shutdown, :transition_to_running, :handle_different_imports, :to_yaml, :psych_to_yaml, :to_yaml_properties, :include_class, :java_kind_of?, :public_send, :initialize_clone, :frozen?, :protected_methods, :java_implements, :public_method, :freeze, :java, :singleton_methods, :untaint, :javafx, :enum_for, :private_methods, :method, :require, :instance_variables, :extend, :instance_variable_set, :respond_to?, :java_name, :respond_to_missing?, :hash, :methods, :gem, :to_java, :java_package, :singleton_class, :public_methods, :to_enum, :display, :tainted?, :instance_variable_defined?, :untrusted?, :define_singleton_method, :nil?, :!~, :com, :instance_of?, :java_require, :javax, :java_signature, :to_s, :===, :suppress_warnings, :tap, :java_annotation, :send, :trust, :instance_variable_get, :is_a?, :eql?, :java_field, :untrust, :<=>, :class, :=~, :org, :taint, :kind_of?, :clone, :initialize_dup, :dup, :==, :!, :equal?, :instance_exec, :object_id, :__id__, :instance_eval, :__send__, :!=]
```

Long story short: in my opinion, this feature, as it is today, is not very useful. Therefore I see two options:

* Remove it from Logstash
* Extend it such that it becomes useful and maybe even extendable by the customer

Read logstash-core/lib/logstash/config/grammar.treetop around method_call and bareword, then inspect the related classes in logstash-core/lib/logstash/config/config_ast.rb and Logstash::Pipeline. The issue is complete only when the project decides whether to remove or extend method_call and the grammar and AST behavior are aligned with that decision.

Written by the indexing model from the issue text.