set catalog feature flag for integration tests (search)

[mkenigs]

Do some combination of:

• Copy tests in search.bats that are impacted by the catalog and run them with the catalog feature flag set. Make any small changes required to get them passing
• Port those tests to unit tests run with the catalog feature set
• Port those tests to serverside tests

In any case:

• Set FLOX_FEATURES_USE_CATALOG=true and _FLOX_USE_CATALOG_MOCK=/dev/null for all other tests in the file
• If anything that isn't minor breaks, skip copied tests and create followup tickets

[zmitchell]

Most of these tests can be converted into unit tests without much effort since we have the ability to seed the client with mock data.

Additional context:

• We have tests that use different search strategies. We no longer have multiple search strategies as far as I can tell, so you'll have to dedup those tests.
• I don't know that the tests verifying the number of results will be very meaningful given that you're seeding the catalog client with test data. At best this is simply verifying that all the results obtained by the client appear in the search output.
• I'm not sure how we propose to test the semver handling since that's now server-side. Semver filtering now only happens on the /resolve endpoint, so those tests should likely be moved elsewhere.
• "'flox search' error message when no results" could be turned into a unit test that detects whether Search::handle returns an error whose .description method contains the desired error message.
• We could refactor the "show results" functions to take impl Write instances instead of assuming stdout/stderr. This lets you pass in buffers during testing, which could be useful for counting search results and verifying that certain error messages are printed.
• There are tests that verify certain packages are in the package database. With catalog service up and running these likely belong in that test suite rather than flox/flox.