fix: fixes autocomplete not working in valid positions because of a Java iterable INTELLIJ-158

[himanshusinghs]

Description

AC was not working in cases where a valid MethodCallExpression was having a Java Iterable as an argument. This PR fixes that by handling the case of Java Iterable and traversing upwards to determine whether a caret position qualifies for AC or not.

Checklist

• New tests and/or benchmarks are included.
• Documentation is changed or added.
• Changelog is updated accordingly.
• I have signed the MongoDB Contributor License Agreement (https://www.mongodb.com/legal/contributor-agreement).

Open Questions

[kmruiz]

There are other ways to define iterables in Java, maybe instead of checking the class of the method, we can check the return type is a Collection or an array? Collections.singletonList is also another way.

I don't think we need to support all possible factory methods right now, but if the cost of supporting them is low I would try it.

[himanshusinghs]

Discussed this over Slack - Checking the return type of the expression is the sure shot way for inferring wether the expression is a Java Iterable or not but then it would also "accidentally" cover cases for iterables that could potentially be modified such as iterables created with new ArrayList interface. For now we decided to rename the interface to isParseableJavaIterable to abstract away how we identify the iterable. It also now support Collections.singletonList (71a30ef)

[github-actions]

Coverage Report

Overall Project	78.34% -0.09%	✅
Files changed	78.99%	✅

File	Coverage
JavaDriverDialectParser.kt	88.33% -0.76%	✅

[github-actions]

🤖 Benchmark Comparison for Merge branch 'main' into fix/INTELLIJ-158

Benchmark	Previous	Current	Change
com.mongodb.jbplugin.jmh.SampleBenchmark.init	2,664,355,353.95 ops/s	2,666,277,643.56 ops/s	0.07%