[Security Solution][DQD][Tech Debt] Colocate components

[kapral18]

addresses #190964

Second in the series of PRs to address general DQD tech debt. Currently this PR build on the work of #190970.

So this PR restructures components to colocate component throughout the hierarchy.

So instead of:

root/
  component1/
  childOfComponent1/
  grandChildOfComponent1/
  component2/
  use_hook_used_for_1/
  use_hook_used_for_2/

we use:

root/
  component1/
    hooks/
      use_hook_used_for_1/
    childOfComponent1/
      grandChildOfComponent1/
  component2/
    hooks/
      use_hook_used_for_2/

PROs of such scaffold:

• complete and clear hierarchical visibility into component structure of the entire DQD codebase
• ability to easily introduce and integrate a new change and calculate its impact on the tree of components
• ability to easily remove colocated functionality without having to scout through the convoluted DQD code
• clear understanding of where shared code should live as opposed to know when its shoved into top level by default with other non shared code
• since nesting too deep has an import name readability tax it forces us to think about not splitting our components into too many small parts but rather keep it balanced, as opposed to now where flat structure incentivizes free and cheap fragmentation as seen with component like .

CONS:

• import names have too many ../../../../../../../../../. It is fixable by ts paths/webpack aliases, but on the other hand especially if there are many of those it's an indication of potential architectural smell, that needs to be addressed (which is a PRO).

Imho, overall visibility trumps any cons and facilitates greater ease of adding new and changing existing functionality with more confidence.

Before

After

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[elasticmachine]

Pinging @elastic/security-threat-hunting-explore (Team:Threat Hunting:Explore)

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 07fcb76

Failed CI Steps

• FTR Configs #69

Test Failures

• [job] [logs] FTR Configs #69 / discover/context_awareness extension getDefaultAppState data view mode should merge and dedup configured default columns with default profile columns

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	5677	5676	-1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	18.0MB	18.0MB	+31.0B

History

• 💔 Build #229606 failed 7aba7ce48b52aa545e8adc281b8dba0a8e615234
• 💚 Build #229261 succeeded f4dd94280f4f879465e131db86d12da104d5c426
• 💛 Build #228830 was flaky dd556494ffc9ce29ee43ac3ce213e45b14be061d

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @kapral18