CLDR-17287 basic performance test for the back end

[srl295]

• execute a bunch of votes all in a row, which calls VoteResolverAPI (refactored) from the unit test to vote and to check the voting results.

CLDR-17287

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[srl295]

@btangmu this is a start, i'm redoing it to go through VoteAPIHelper!

[srl295]

@btangmu i'm getting the 'read' side going too!

[btangmu]

ok if TODOs get done in subsequent pr

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• tools/cldr-apps/src/main/java/org/unicode/cldr/web/api/STError.java is different
• tools/cldr-apps/src/main/java/org/unicode/cldr/web/api/VoteAPIHelper.java is different
• tools/cldr-apps/src/main/java/org/unicode/cldr/web/CookieSession.java is now changed in the branch
• tools/cldr-apps/src/test/java/org/unicode/cldr/unittest/web/TestSTFactory.java is different
• tools/cldr-apps/src/test/resources/org/unicode/cldr/unittest/web/data/TestVotePerf.xml is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[btangmu]

approving reluctantly, see comment about deep nesting due to unnamed handler that needs to be named instead of being stuffed inside the parentheses in myReader.setHandler(...)

[btangmu]

this code is too deeply nested! the root of the problem starts with myReader.setHandler(...) followed by all the code for the unnamed handler being within the parentheses. it would be sooooo much better to give the handler a name, and just put its name in the parentheses, and define the handler as a named class outside of runDataDrivenTest to prevent runDataDrivenTest from being 600+ lines long

the deep nesting probably causes the formatter to insert more newlines, adding insult to injury