[Onboarding] Introduce search index details page locator and update all reference

[saarikabhasi]

Summary

• Introducing new locator for onboarding search_indices plugin index details page - SEARCH_INDEX_DETAILS_LOCATOR_ID.
• In stack, Updated view index details usage(connector table, connector details page, search application & web crawler) to use this locator to navigate to onboarding index details page ONLY when its search - Elasticsearch solution nav
• Index management view index details would use extensionService with active solution id check in search_indices plugin
• verified locally existing FTR & unit tests
• Added FTR for index management in functional_search tests for search solution nav and classic nav

demo.mov

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios
• Flaky Test Runner was used on any tests changed

[kibanamachine]

Flaky Test Runner Stats

🎉 All tests passed! - kibana-flaky-test-suite-runner#7628

[✅] x-pack/test/functional_search/config.ts: 25/25 tests passed.
[✅] x-pack/test_serverless/functional/test_suites/observability/common_configs/config.group1.ts: 25/25 tests passed.
[✅] x-pack/test_serverless/functional/test_suites/search/common_configs/config.group1.ts: 25/25 tests passed.
[✅] x-pack/test_serverless/functional/test_suites/search/config.ts: 25/25 tests passed.
[✅] x-pack/test_serverless/functional/test_suites/security/common_configs/config.group1.ts: 25/25 tests passed.

see run history

[kibanamachine]

Flaky Test Runner Stats

🎉 All tests passed! - kibana-flaky-test-suite-runner#7627

[✅] x-pack/test/api_integration/apis/search/config.ts: 25/25 tests passed.
[✅] x-pack/test/functional_search/config.ts: 25/25 tests passed.
[✅] x-pack/test_serverless/api_integration/test_suites/search/common_configs/config.group1.ts: 25/25 tests passed.
[✅] x-pack/test_serverless/api_integration/test_suites/security/common_configs/config.group1.ts: 25/25 tests passed.
[✅] x-pack/test_serverless/api_integration/test_suites/observability/common_configs/config.group1.ts: 25/25 tests passed.
[✅] x-pack/test_serverless/functional/test_suites/search/config.ts: 25/25 tests passed.

see run history

[pheyos]

x-pack/test/functional/page_objects/index.ts changes LGTM

[joemcelroy]

these tests are going to collide with Yan's changes. They are broadly similar but theres likely slight differences in approach.

I suggest we wait until @yansavitski changes are merged in then we can rebase the FTR tests.

[yansavitski]

LGTM

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: 8116d7d

Failed CI Steps

• Check Types

History

• 💛 Build #264912 was flaky 601f509
• 💚 Build #264822 succeeded ca8dc1d
• 💔 Build #264553 failed 4023011
• 💚 Build #262552 succeeded adba282

[TattdCodeMonkey]

❌ This is not a good way to use useCallback(). That should be used if you want to create a onClick handler for the EuiLink. This is being used to generate props at render time, which feels like a code smell to me.

What you likely want is something more like this:

const onSearchIndicesClick = useCallback(
  (event: React.MouseEvent<HTMLAnchorElement>, indexName: string) => {
    if (!searchIndicesLocator) return;
    e.prevenDefault();
    searchIndicesLocator.getUrl({ indexName }).then((url) => {
      navigateToUrl(url, {
        shouldNotCreateHref: true,
        shouldNotPrepend: true,
      });
    });            
  },
  [navigateToUrl, searchIndicesLocator]
);
...
health === 'unknown' ? name : <EuiLink data-test-subj='search-application-index-link' href={searchIndicesLocator.getRedirectUrl({})} onClick={(e) => onSearchIndicesClick(e, name)}>{name}</EuiLink>

but the promise in the useCallback is problematic, but likely the best option if we do this here. A plus would be this function could be shared between the link and and the action instead of having two handlers.

BUT a better option might be to create a link component that takes the index name as a prop and handles all this logic with the locator and share plugin start in that component which is rendered in the column render() it could then be used in this file and the flyout

[TattdCodeMonkey]

see other comment.

[TattdCodeMonkey]

why is this usage of the locator so different from the others? if we can make a sync call that returns the value or undefined we should likely prefer this pattern.