Adds case insensitive decorators.

[cheqianh]

Description

This PR fixs the issue #51. Ion is case sensitive and path extractor's case insensitive flag is targeting to the field names only (E.g. it doesn't affect fields within a nested struct).

Discussed with jobarr-amzn, one of the most scalable ways to solve the issue is implementing a case insensitive decorator which wraps an Ion Container. For read methods such as containsKey, get, iterator, the decorator should return a case insensitive decorator wrapped Ion Value as well without changing the underlying Ion struct to make sure all fields within a nested container are still case insensitive.

Reproduce the issue (solved in this PR):

Ion text: {foo: {Bar: 1}}
Hive QL:

CREATE EXTERNAL TABLE case( foo struct<bar:int> )
ROW FORMAT SERDE 'com.amazon.ionhiveserde.IonHiveSerDe' 
WITH SERDEPROPERTIES ("ion.path_extractor.case_sensitive"="false") 
STORED AS INPUTFORMAT 'com.amazon.ionhiveserde.formats.IonInputFormat' 
OUTPUTFORMAT 'com.amazon.ionhiveserde.formats.IonOutputFormat' 
LOCATION '/user/data'; 

Reading from Hive (Before):

hive > Select * from case                                              
OK                                                                     
null     // can't find bar!

It shows (Now):

hive > Select * from case                                              
OK                                                                     
{bar: 1} 

Root:

The root of this issue is because ion-java-path-extractor will call the callback method directly and return the IonStruct without stepping into it (because it was no need to spend extra time to step-in the struct) when ion-java-path-extractor matches the desired search path. As a result, cases of filed names within a struct are never changed (e.g. they are still uppercase).

Test:

Passed unit tests/integration tests. In addition, it worked correctly for #51 example in the EMR environment.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jobarr-amzn]

Looks good! It's too bad that it's a pain to upgrade to Kotlin 1.5 right now, we're missing those assertions.

I also wonder whether it would be possible to somehow use Kotlin in our implementation and not just in test - it would make forwarding/decorator classes so much easier to implement.