SNOW-2022698: Rename relaxed_ordering param into enforce_ordering and update default setting

[sfc-gh-helmeleegy]

1. Which Jira issue is this PR addressing? Make sure that there is an accompanying issue to your PR.

   Fixes SNOW-2022698

2. Fill out the following pre-review checklist:

   • I am adding a new automated test(s) to verify correctness of my new code
     • If this test skips Local Testing mode, I'm requesting review from @snowflakedb/local-testing
   • I am adding new logging messages
   • I am adding a new telemetry message
   • I am adding new credentials
   • I am adding a new dependency
   • If this is a new feature/behavior, I'm adding the Local Testing parity changes.
   • I acknowledge that I have ensured my changes to be thread-safe. Follow the link for more information: Thread-safe Developer Guidelines
   • If adding any arguments to public Snowpark APIs or creating new public Snowpark APIs, I acknowledge that I have ensured my changes include AST support. Follow the link for more information: AST Support Guidelines

3. Please describe how your code solves the related issue.

   Rename relaxed_ordering param into enforce_ordering per @sfc-gh-dolee's recommendation. The default value for the new param will be enforce_ordering=False which has the opposite meaning of the previous default value relaxed_ordering=False.
   Tests that were calling read_snowflake using the old default setting will switch to using the new default setting, which results in smaller query counts.

[sfc-gh-snowflakedb-snyk-sa]

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)

[sfc-gh-mvashishtha]

This is mostly good, but I'm leaving comments that are mostly asking about cases where I think that we can't rely on the ordering from read_snowflake(), but we assume a certain order.

Some of these test cases seem to have the ordering issue even prior to this PR because we were already testing with relaxed_ordering=True, while others now only rely on a non-guaranteed ordering because they are using the new default of enforced_ordering=False. Could you please take on a JIRA ticket to fix 1) in another PR, and also address 2) in this PR? All of this assumes that I've correctly both sets of ordering issues :)

[sfc-gh-helmeleegy]

This is mostly good, but I'm leaving comments that are mostly asking about cases where I think that we can't rely on the ordering from read_snowflake(), but we assume a certain order.

Some of these test cases seem to have the ordering issue even prior to this PR because we were already testing with relaxed_ordering=True, while others now only rely on a non-guaranteed ordering because they are using the new default of enforced_ordering=False. Could you please take on a JIRA ticket to fix 1) in another PR, and also address 2) in this PR? All of this assumes that I've correctly both sets of ordering issues :)

Fair point. Calls using the new default are now followed by an explicit sort step to make sure that we avoid test flakiness.

[sfc-gh-yuwang]

the changes looks good to me, but I want to ask to run our daily precommit test/pandas precommit test on this PR to see if it has any side effects since this is such a big PR

[sfc-gh-helmeleegy]

the changes looks good to me, but I want to ask to run our daily precommit test/pandas precommit test on this PR to see if it has any side effects since this is such a big PR

@sfc-gh-yuwang Sure. Here are the two jobs. They both look good:
https://github.com/snowflakedb/snowpark-python/actions/runs/14458947108
https://github.com/snowflakedb/snowpark-python/actions/runs/14458960726