ORC, Hive: Fix column projection when reading ORC files and orc.force.positional.evolution is set to true on the default configuration

[pvary]

After this change (HIVE-20129 Revert to position based schema evolution for orc tables) in Hive the Iceberg ORC column projection is not working as expected.

The effect:

• If the table has 3 columns (customer_id, first_name, last_name)
• And the query requests the last 2 columns (first_name, last_name)
• We will read the first 2 (customer_id, first_name) instead of the requested ones

I think it would be good to turn off this config for our Iceberg ORC readers as we expect it to be false anyway and other systems using Iceberg might need it to be set differently.

The patch contains 3 groups of changes:

• Test infra changes so we can change HMS configuration (this is used for HiveCatalog FileIO creation)
• Actually setting the orc.force.positional.evolution to true in the tests - this causes TestHiveIcebergStorageHandlerLocalScan.testColumnSelection() to fail
• Setting orc.force.positional.evolution to false in ORC.ReadBuilder to override the configuration values to the expected one - tis fixes the test failures

[rdblue]

If I understand correctly, the id-based projection requests fields by name and if the projection type is changed in the Hive conf, that causes the wrong projection. Right? If so, then I agree with the fix to set this in the conf that we use for readers.

[rdblue]

Nit: if initConf returned the configuration, this could be one line still: this.hiveConf = initConf(conf, port);

[pvary]

Before the change the configuration was created in newHiveConf(). The new method changes values in the conf parameter. The change meant to emphasize that we are not creating a new conf, only changing values in the one got in the parameter list.

Shall we move back to create a new config and initialize that?

[rdblue]

If conf is passed in, I think the change to initConf makes sense. I just think the patch could be slightly smaller. Not a blocker, though.