Do not override encoding set during initialisation

[kp666]

encoding set during initialisation of sax parser gets replaced to ASCII when parsing.
Fix: check if encoding has already been set.

[flavorjones]

Hi, there's a CI failure for this PR that I think is related, as it's an encoding test:

https://ci.nokogiri.org/teams/nokogiri-core/pipelines/nokogiri-pr/jobs/ruby-2.6-system/builds/60

I'd also like this PR to contain a test.

[kp666]

@flavorjones I am not sure if to mutate encoding while passing encoding via parse_io.
please give directions here.

[codeclimate]

Code Climate has analyzed commit 50d7495 and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 50.0% (80% is the threshold).

This pull request will bring the total coverage in the repository to 46.3%.

View more on Code Climate.

[flavorjones]

The current CI failures are not due to this commit -- will take a look now.

[flavorjones]

ok - remaining failures would be addressed by a rebase onto master, regardless this is OK to merge ...

BUT I want to think about edge cases before doing so.

[kp666]

My issue was that even when i set encoding to 'UTF-8' when the parser is initialised, parser.parse was calling parse_io without encoding. This meant that encoding was getting changed to 'ASCII' as per the old code.
IMO parse_io api seems a bit weird since parse_file and parse_memory apis do not take an additional encoding argument, and neither does mutate the 'encoding' instance variable, where as parse_io is capable of mutating encoding.

[flavorjones]

Just rebased onto master to get the checks green ...

[flavorjones]

Rebased again to try to get CI green ...

[flavorjones]

I've rebased this again onto current main

[flavorjones]

LGTM! Merging. Thank you for your patience!!!

[flavorjones]

I've credited you in the changelog in 243eab5. This will be in v1.14.0.