Use `count` expectation on `all` finder for patient specs (address flakey recent searches specs)

What does this MR do?

Use count expectation so the all finder will wait for things to be in place (patience 🙇). Address flakey recent searches specs

bundle exec spring rspec spec/features/issues/filtered_search/recent_searches_spec.rb

Are there points in the code the reviewer needs to double check?

I tried out a couple other ways to accomplish this but they had some shortcomings.

1. Check item count

This isn't very robust at the 5 limit range but we don't have any tests that max things out yet. And it gave some execution expired failures in the pipelines here 😓.

def wait_for_new_recent_search_item(item_count_before)
    Timeout.timeout(Capybara.default_max_wait_time) do
      loop until item_count_before == 5 ||
          all('.filtered-search-history-dropdown-item', visible: false).count > item_count_before
    end
  end

2. Find text of the new item

Fails because searches can contain quotes that get stripped in the JS and text spacing issues. Also would fail when the same text search was used sequentially (not currently an issue though).

def wait_for_recent_search_item(text)
  Timeout.timeout(Capybara.default_max_wait_time) do
    loop until find('.filtered-search-history-dropdown-item', text: text, visible: false)
  end
end

3. Compare element nodes

Capybara doesn't like comparing ObsoleteNode and throws an error

def wait_for_new_recent_search_item(old_search_item)
  Timeout.timeout(Capybara.default_max_wait_time) do
    loop until first('.filtered-search-history-dropdown-item', visible: false) != old_search_item
  end
end

Does this MR meet the acceptance criteria?

• Tests added for this feature/bug
• Review
  • Has been reviewed by Frontend
  • Has been reviewed by Backend
• Conform by the merge request performance guides
• Conform by the style guides
• Squashed related commits together

What are the relevant issue numbers?

Closes #34435 (closed)