SOLR-14219: Revert changes in OverseerSolrRespose and move serialization

[tflobbe]

This PR is an attempt to fix the serialization incompatibility introduced by SOLR-14095. @andywebb1975 has proposed a different approach in #1210, but I believe this may better resolve the problem. See discussion in #1210

[andywebb1975]

This looks like a good approach to me - will give it a closer look and try it out in my dev environment tomorrow (UK time)!

[andywebb1975]

The new approach works on my env with a mixed pool - thanks! Note your related commit 5f5ef58 is in branch_8x and not master - I had to drop that out before I could cherry-pick 3c52152, and then apply the same fix to the new OverseerSolrResponseSerializer to get a working 8.5.0 build: andywebb1975@dee5ac5. I assume this backwards-compatibility will disappear in 9.0.0 so maybe this PR should be into branch_8x rather than master?

Andy

[tflobbe]

Thanks @andywebb1975. Regarding that commit, I'm wondering what we should do. We could keep the deserialization as an option (otherwise, even with a full restart of a Solr cluster, new nodes wouldn't be able to read these from ZooKeeper), however that still allows people to shoot themselves in the foot and allow this unsafe mode in Solr.

[andywebb1975]

I see you're working on this right now now so you may have this in hand - but I think the OverseerSolrResponseSerializer in branch_8x needs to use IOUtils because the .readAllBytes() method doesn't exist in Java 8. Presumably that means the master branch needs that too, at least temporarily, followed by a master-only revert to the Java 11 version?

[tflobbe]

I Used IOUtils in 8x: 37d4121

[andywebb1975]

Oh yes, thanks - I didn't notice they were different commits. I'm running a build now to test the updated branch_8x in my dev stack.

[andywebb1975]

That's working nicely, thanks Tomás!

[tflobbe]

Yes, maybe not the best approach. I resolved the commit issue while resolving the cherry-pick conflict. Thanks for verifying!