CLDR-17461 Forum posts in vetting view, boost performance, change icons

[btangmu]

-Add a cache localeForumStatusMap in SurveyForum.java

-New class SurveyForum.LocaleForumStatus

-Get all the status for a locale with a single sql call

-Clear the cache for a locale when a post is added/closed

-Revise icons in the Comparison (English) column: 👁️‍🗨️ and 💬

-👁️‍🗨️ means: This item has one or more forum posts, some of which are open

-💬 means: This item has one or more forum posts, all of which are closed

-Change let to const for two items in cldrSurvey.mjs; remove @Property

-Call updateRowEnglishComparisonCell even if isSetup, and always removeAllChildNodes; old optimization assumed the cell contents never changed

CLDR-17461

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[btangmu]

Running this locally with JProfiler, there's no longer a major hot spot for the sql query. PathForumStatus is 0.0% at the bottom of this screenshot:

[btangmu]

It turns out that making/closing a forum post DOES update json.localeStamp, but the main table cell wasn't getting updated due to an old optimization based on an assumption that the Comparison (English) column never changes!

In cldrTable.mjs:

  /*
   * Set up the "comparison cell", a.k.a. the "English" column.
   */
  if (comparisonCell && !comparisonCell.isSetup) {
    updateRowEnglishComparisonCell(tr, theRow, comparisonCell);
  }

If I remove && !comparisonCell.isSetup then the cell updates, but in a funny way, new data adding to old data instead of replacing it:

That can be fixed by adding this line with removeAllChildNodes:

function updateRowEnglishComparisonCell(tr, theRow, cell) {
  cldrDom.removeAllChildNodes(cell);

I'll follow up...

[srl295]

looks great to me!

[btangmu]

My second commit fixed the comparisonCell problem; I'll squash...

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[srl295]

My second commit fixed the comparisonCell problem; I'll squash...

squash is usually not needed, because we squash on merge anyway. It actually makes it harder to see what the additional change was separately.

[btangmu]

@srl295 "we squash on merge anyway" -- was that always true? anyway, good to know, I agree the changes in a PR are often easier to see without the squashing