### Apache Airflow version

2.7.0

### What happened

Actual Behavior:
Upon entering a keyword in the search bar, no search results are shown, and the UI remains unchanged. The search function seems to be non-responsive.
You can see in the address bar, `undefined` appears instead of valid value.
<img width="1427" alt="step-1" src="https://github.com/apache/airflow/assets/17428690/10da4758-a614-48c8-a926-6bc69f8595f1">
<img width="1433" alt="step-2" src="https://github.com/apache/airflow/assets/17428690/be8912f2-e49e-40ca-86f7-1803b516482e">


### What you think should happen instead

Expected Behavior:
When I use the search function in the Airflow UI, I expect to see a list of results that match the entered keyword. This should help me quickly locate specific DAGs or tasks within the UI.

### How to reproduce

Steps to Reproduce:
1. Log in to the Airflow UI.
2. Navigate to the "Connections" list view by clicking on the "Connections" link in the navigation menu or by directly visiting the URL: <your_airflow_ui_url>/connection/list/.
3. Attempt to use the search function by entering a keyword.
4. Observe that no search results are displayed, and the search appears to do nothing.

### Operating System

MacOS

### Versions of Apache Airflow Providers

_No response_

### Deployment

Other

### Deployment details

Standalone Airflow via official Quickstart documentation

### Anything else

I encounter this issue since `Airflow 2.6.0`. It was fine on `Airflow 2.5.3`.

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

"""
    Replace extra dependencies with provider package.
    The intention here is that when the provider is added as dependency of extra, there is no
    need to add the dependencies separately. This is not needed and even harmful, because in
    case of future versions of the provider, the dependencies might change, so hard-coding
    dependencies from the version that was available at the release time might cause dependency
    conflicts in the future.
    Say for example that you have salesforce provider with those deps:
    { 'salesforce': ['simple-salesforce>=1.0.0', 'tableauserverclient'] }
    Initially ['salesforce'] extra has those dependencies, and it works like that when you install
    it when INSTALL_PROVIDERS_FROM_SOURCES is set to `true` (during the development). However, when
    the production installation is used, The dependencies are changed:
    { 'salesforce': ['apache-airflow-providers-salesforce'] }
    And then, 'apache-airflow-providers-salesforce' package has those 'install_requires' dependencies:
            ['simple-salesforce>=1.0.0', 'tableauserverclient']
    So transitively 'salesforce' extra has all the dependencies it needs and in case the provider
    changes its dependencies, they will transitively change as well.
    In the constraint mechanism we save both - provider versions and its dependencies
    version, which means that installation using constraints is repeatable.
    For K8s and Celery which are both "Core executors" and "Providers" we have to
    add the base dependencies to core as well, in order to mitigate problems where
    newer version of provider will have less strict limits. This should be done for both
    extras and their deprecated aliases. This is not a full protection however, the way