Fix non-deterministic test - testSelectIntoPath

[mohitbadve]

Description

The test org.apache.iotdb.db.queryengine.plan.analyze.AnalyzeTest#testSelectIntoPath fails under NonDex tool which detects non-deterministic nature of tests with when non-deterministic data structures are used. The failure here is observed because the results we get from analysis.getIntoPathDescriptor().getSourceTargetPathPairList() are not always in determinstic order.

How to Reproduce

mvn -pl iotdb-core/datanode edu.illinois:nondex-maven-plugin:2.1.7:nondex 
-Dtest=AnalyzeTest#testSelectIntoPath
-DnondexRuns=10

Error

[INFO] Running org.apache.iotdb.db.queryengine.plan.analyze.AnalyzeTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.050 s <<< FAILURE! -- in org.apache.iotdb.db.queryengine.plan.analyze.AnalyzeTest
[ERROR] org.apache.iotdb.db.queryengine.plan.analyze.AnalyzeTest.testSelectIntoPath -- Time elapsed: 1.010 s <<< FAILURE!
java.lang.AssertionError: expected:<[<root.sg.d1.s1,root.sg.d1.t1>, <root.sg.d2.s1,root.sg.d2.t1>, <root.sg.d1.s2,root.sg.d1.t2>, <root.sg.d2.s2,root.sg.d2.t2>]> but was:<[<root.sg.d2.s1,root.sg.d2.t1>, <root.sg.d1.s1,root.sg.d1.t1>, <root.sg.d2.s2,root.sg.d2.t2>, <root.sg.d1.s2,root.sg.d1.t2>]>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:120)
	at org.junit.Assert.assertEquals(Assert.java:146)
	at org.apache.iotdb.db.queryengine.plan.analyze.AnalyzeTest.testSelectIntoPath(AnalyzeTest.java:754)...

Proposed Solution

Instead of asserting the lists directly, assert the lists without considering the order.
Please let me know if you have any questions or need any additional justification/changes from my side.

---

This PR has:

• been self-reviewed.
  • concurrent read
  • concurrent write
  • concurrent read and write
• added documentation for new or modified features or behaviors.
• added Javadocs for most classes and all non-trivial methods.
• added or updated version, license, or notice information
• added comments explaining the "why" and the intent of the code wherever would not be obvious
  for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold
  for code coverage.
• added integration tests.
• been tested in a test IoTDB cluster.

---

Key changed/added classes (or packages if there are too many classes) in this PR