Add filter strategy for optimized entity name/property queries

[seadowg]

Closes #5623

Blocked by #6261
Blocked by getodk/javarosa#780
Blocked by getodk/javarosa#782

The "closes" here is slightly cheating as we'll also need to a better implementation of EntitiesRepository (using SQLite most likely) to get the real world load time gains. Additionally, the total memory footprint won't have dropped - the current EntitiesRepository implementation requires a whole list in memory for both getById and getByProperty. That all said, we're assuming that our new implementation (which we'll build as part #6012) will give us faster lookups and memory use that's only increased by the number of results (as opposed to needing the whole list in memory ever). @lognaturel is putting together a project for testing all this, and we've decided that this implementation is a good enough structural change to serve as a foundation we can tweak to get the performance we want.

Why is this the best possible solution? Were any other approaches considered?

The basic idea here is to query the EntitiesRepository for name= and <property>= predicates instead of letting JavaRosa use its own built in FilterStrategy chain. Combined with "partial parsing" (provided by LocalEntitiesInstanceProvider) and the new DataInstance#replacePartialElement this lets us keep the majority of the entity list out of memory until its all needed (like when we show an unfiltered select).

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

This risk here will be to forms that use filtered selects and calculations based on secondary instances. Entity forms are the most likely to have problems, but there is some risk that there are some unintended consequences for non-entity forms as well.

There's no need to test the actual performance increase/decrease here. As I said in the introduction, that will be hard to properly verify until other changes are made.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[seadowg]

I'm thinking we'll eventually pull out an interface (InstanceDataAdapter for example) from this to use for normal secondary instances as well. The entity InstanceProvider and FilterStrategy are both actually generic enough to support that with minimal changes and could be pulled out into another package, but that felt too far for the moment.

[seadowg]

@grzesiek2010 OK that's the missed comment fixed!

[seadowg]

Marking this as a draft while I fix problems with the local entities setting that are complicated by JavaRosa's static state.

[seadowg]

@grzesiek2010 ok that's fixed!

[dbemke]

Tested with Success!

Verified on a device with Android 10

Verified Cases:

• exploratory tests in forms with entities
• forms with filtered selects and entities
• regression checks in forms with selects and forms with secondary instances

[WKobus]

Tested with Success!

Verified on a device with Android 14