Use new paramSwitch enum for row matchfinder and block splitter

[senhuang42]

This PR introduces a minor refactor that adds a new param that generalizes the idea of a boolean parameter that can be user-enabled, user-disabled, or determined at runtime by the library what the value should be.

The two discussion points are:
Should the unstable ZSTD_literalCompressionMode_e get moved to this as well, with the associated advanced param renamed to ZSTD_c_useLiteralCompression (like *_useRowMatchFinder and *_useBlockSplitter)?

LDM falls into this category, but the advanced parameter ZSTD_c_enableLongDistanceMatching is already stable, and therefore the type can't be changed to the new enum type. Internally, we could still implement the selection logic as the new enum type, but then the advanced param and the internals would diverge, unlike any of the other paramSwitch-type features.

Note: #2780 will be rebased on top of this

[Cyan4973]

LDM falls into this category, but the advanced parameter ZSTD_c_enableLongDistanceMatching is already stable, and therefore the type can't be changed to the new enum type. Internally, we could still implement the selection logic as the new enum type, but then the advanced param and the internals would diverge, unlike any of the other paramSwitch-type features.

I believe that's nonetheless a good way forward, and likely a better situation than the one we are currently in.
We are effectively already enabling ldm as an auto mode already, even though it's "officially" set to 0==off.

The way I see it, we could employ this strategy :

• Internally, the flag does respect the new paramSwitch model, with 0 == auto as the starting value.
• At interface level, auto doesn't exist. The API only allows selecting "force disable" or "force enable". Hence 0 -> 1 and 1 -> 2.
  • This way, it respects the current interface contract, which remains "stable".
• And it still allows automatic ldm decision, as we effectively do today (ldm is automatically enabled when windowLog >= 27).
• The downside is that there is no way to "set" ldm to auto. The only way to have auto is to not set ldm at all, or to reset the context.
• If it was a problem, we could introduce a new advanced parameter just to set ldm to auto. That being said, I don't see such as need for the time being.

[terrelln]

If it was a problem, we could introduce a new advanced parameter just to set ldm to auto. That being said, I don't see such as need for the time being.

Yeah, if we need this functionality, we can just add a new parameter like ZSTD_useLongDistanceMatching (or whatever naming scheme we choose for these 3-state parameters), and eventually deprecate ZSTD_enableLongDistanceMatching.

[Cyan4973]

I did not mention it earlier, but just as a confirmation :

Should the unstable ZSTD_literalCompressionMode_e get moved to this as well, with the associated advanced param renamed to ZSTD_c_useLiteralCompression

Yes, we should. It will be much cleaner.

[terrelln]

This PR introduces a lot of insignificant changes (which is fine). Can you point out exactly which lines introduce functional changes?

Even better would be to separate into two commits (or two PRs). One to switch to ZSTD_ParamSwitch_e, and one to make the functional change.

[senhuang42]

Actually there should only be insignificant changes and no real functional changes - these changes appear to be a bug where I missed one of the params in regressiontest.

[senhuang42]

Turns out I introduced a bug where I was incorrectly passing in the value of the useRowMatchFinder param into the function resolveBlockSplitterMode, causing block splitter to always get enabled when row hash is. Perils of copy-paste..

I split this PR into two commits, one for ldm, since it's a bit different, and one for the rest. Basically there are no real changes, and every change that isn't a direct name replacement is a small adjustment in order to accommodate the naming change or int->enum changes. All the results.csv changes are just switching between 1 and 2 in row match finder, since the meaning of 1 and 2 changed for rowhash's enum. Lmk if there's is a better scheme to divide this up for the sake of making review easier.