The semantic of the event in logstash (Text Encoding)

While working on https://github.com/logstash-plugins/logstash-input-jdbc/issues/143 some thoughts have pop up for me regarding what we expect from the event holder in logstash. I want to open this issue so we can reach a common viewpoint on what we expect from it and also might generate a nice source of knowledge to be all in the same page for expectations when handing data into the event.

First of all what I've seen:

``` bash
skywalker% cd logstash-2.2.0
skywalker% ls
CHANGELOG.md CONTRIBUTORS Gemfile Gemfile.jruby-1.9.lock LICENSE NOTICE.TXT bin lib vendor
skywalker% head Gemfile
# This is a Logstash generated Gemfile.
# If you modify this file manually all comments and formatting will be lost.

source "https://rubygems.org"
gem "logstash-core", "2.2.0"
gem "logstash-core-event", "2.2.0"
gem "file-dependencies", "0.1.6"
gem "ci_reporter_rspec", "1.0.0", :group => :development
gem "simplecov", :group => :development
gem "coveralls", :group => :development
skywalker% ./bin/logstash irb
irb(main):002:0> require "logstash/event"
=> true
irb(main):003:0> event = LogStash::Event.new({ "field" => "value".force_encoding("ISO-8859-1")})
=> #, @cancelled=false, @data={"field"=>"value", "@version"=>"1", "@timestamp"=>"2016-06-30T09:28:39.300Z"}, @metadata={}, @accessors=#"value", "@version"=>"1", "@timestamp"=>"2016-06-30T09:28:39.300Z"}, @lut={}>>
irb(main):004:0> event["field"]
=> "value"
irb(main):005:0> event["field"].encoding
=> #
irb(main):006:0>
```

```
skywalker% cd logstash-5.0.0-alpha3
skywalker% ls
CHANGELOG.md CONTRIBUTORS Gemfile Gemfile.jruby-1.9.lock LICENSE NOTICE.TXT bin config lib vendor
skywalker% head Gemfile
# This is a Logstash generated Gemfile.
# If you modify this file manually all comments and formatting will be lost.

source "https://rubygems.org"
gem "logstash-core", "5.0.0.alpha3"
gem "logstash-core-event-java", "5.0.0.alpha3"
gem "logstash-core-plugin-api", "2.1.6"
gem "file-dependencies", "0.1.6"
gem "ci_reporter_rspec", "1.0.0", :group => :development
gem "simplecov", :group => :development
skywalker% ./bin/logstash irb
--- jar coordinate com.fasterxml.jackson.core:jackson-annotations already loaded with version 2.7.1 - omit version 2.7.0
--- jar coordinate com.fasterxml.jackson.core:jackson-databind already loaded with version 2.7.1 - omit version 2.7.1-1
ERROR: too many arguments

See: 'bin/logstash --help'
skywalker% ./bin/logstash --interactive=irb
--- jar coordinate com.fasterxml.jackson.core:jackson-annotations already loaded with version 2.7.1 - omit version 2.7.0
--- jar coordinate com.fasterxml.jackson.core:jackson-databind already loaded with version 2.7.1 - omit version 2.7.1-1
irb(main):001:0> require "logstash/event"
=> false
irb(main):002:0> event = LogStash::Event.new({ "field" => "value".force_encoding("ISO-8859-1")})
=> 2016-06-30T09:30:51.171Z %{host} %{message}
irb(main):004:0> event.get("field")
=> "value"
irb(main):005:0> event.get("field").encoding
=> #
irb(main):006:0>
```

as you can see in the previous examples, this shows how for the ruby event the string encoding is
preserved, for the java event is handled as `UTF-8`, keep in mind both initial strings where `ISO-8859-1`.

I've a few open questions regarding this that would be nice to see what do you think.

Until the introduction of the java event, the encoding was handled by the codecs through the [charset utility class](https://github.com/elastic/logstash/blob/master/logstash-core/lib/logstash/util/charset.rb), who basically try it best to encode strings to UTF-8. So basically the ruby event is a placeholder, what you put in is what you get out, responsability of the class client to do the encoding transformations.

With the introduction of the java event this behaviour changed now, if we put an non UTF-8 string it will be transformed to UTF-8 OOTB.

As I understand is in the benefit of the pipeline filters to have data transformed to UTF-8, for example for json, however, here are my open thoughts:
- Do we aim to keep the old ruby event behaviour with the java event?
- By opening the door to have non UTF-8 string encoding, are we having some filters fail, who might be expecting this format? how should they fail?
- Is the transformation to UTF-8 going to cause problem when people might like to keep their original encoding? does this makes sense?
- If as happens now, all strings are converted to `UTF-8` in the java event (like now), are the codecs that do charset transformations need anymore?