Review numeric conversions in the `convert` filter mutation

[PeteGillinElastic]

The Elasticsearch team have an open issue to review the behaviour of the ES convert processor for numeric conversions. This was opened in response to a user request to change the behaviour. The first steps were to investigate, document, and add test coverage for the current behaviour. We are now ready to look at whether to make any changes. One factor we are concerning is to what extent the behaviour of the ES processor aligns with the Logstash filter mutation (and the Beats ingest processor): all other things being equal, we think that the user is better served if there are fewer inconsistencies across the products.

To establish the current behaviour, it would help to run the list of test cases we have built out for the ES processor against the Logstash filter mutation, and identify any cases where the behaviour differs. These cases are described in this CSV: convert_list.csv. The first three columns give the type of the input value (as a Java type, in our case), the input value itself, and the target type of the conversion; for the cases where the processor successfully converts the value, the fourth and fifth columns give the output type and value; for the cases where the processor throws an exception, the fourth column says THROWS and the fifth is empty.

Thanks for your help.