Follow up: Update FastSearch instance instead of recreating it on data change in SearchRouter

[hannojg]

This is a follow up from this PR:

• Search suffix tree implementation #48652

which was created for this issue ticket originally:

• [HOLD for payment 2025-01-07] [Performance] Typing in search is very laggy for big accounts #46591

This is a follow up task. In the PR we implemented a new tree structure to enable faster searches. Right now for every data change we create a new FastSearch instance which is quite inefficient. We want to:

• Create the FastSearch instance once, and update it on data changes
• Right now the FastSearch instance is quite disconnected from the OptionListUtils. We should see if we can consolidate the FastSearch and OptionListUtils.
  • I think it should be possible to maybe create a search tree for the whole app, which can then be used for different use cases / all the use cases OptionListUtils is serving

[melvin-bot]

@hannojg, this Monthly task hasn't been acted upon in 6 weeks; closing.

If you disagree, feel encouraged to reopen it -- but pick your least important issue to close instead.

[hannojg]

@mountiny can you please reopen? The initial PR for changing the search algorithm to a search tree took longer than anticipated. We are going to look into these items next, so it's still l a priority!

(Somehow no overdue label was ever added?)

[melvin-bot]

@hannojg, this Monthly task hasn't been acted upon in 6 weeks; closing.

If you disagree, feel encouraged to reopen it -- but pick your least important issue to close instead.

[hannojg]

Can we please reopen this? @Nodonisko is going to pick up this one

[Nodonisko]

Started to work on this, can we reopen it?

[hannojg]

The performance implications of this have popped up here: https://margelo.slack.com/archives/C05LX9D6E07/p1745490519573089

can we please reopen this as we prioritized this again @mountiny ? thanks!