[Infra UI] Replace IFieldType references

[Kerry350]

Summary

Fixes #107885

Replaces all instances of IFieldType with suitable replacements.

Due to the super permissible nature of the IFieldType interface there were some types that were just represented incorrectly. But, because IFieldType designated most fields as optional it didn't really surface the type mismatches.

E.g. on the metrics side the derived index pattern was often designated as a DataViewBase, and in many ways it looks like one, the problem with the base type is it also expects the fields to be of the base version. However, we actually use a custom type for the representation there. It's not quite the "full" field, nor the base type, which is why it made more sense to introduce a new accurate type.

Over on the logs side it may well make more sense for some sections of code to use ResolvedLogSourceConfiguration['fields'] rather than relying on the underlying, backing types. However, I had issues getting that to play nicely where we use supportedFields in the alerting code (even though there should have been no type mismatch), so instead kept this as the DataViewField type.

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 8b66df7
• Storybooks Preview

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
infra	917	918	+1

Async chunks

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

id	before	after	diff
infra	988.6KB	988.5KB	-63.0B

Unknown metric groups

References to deprecated APIs

id	before	after	diff
infra	237	13	-224

History

• 💚 Build #13109 succeeded a4b90e41df9f16bd6ddc0b12ed7e6af54855a195
• 💔 Build #12923 failed 83cd49df5181f335ada5f854a7823479dacccc58

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

cc @Kerry350

[weltenwort]

Thanks for the explanation! Out of curiosity, what brought you to this opinion?

Over on the logs side it may well make more sense for some sections of code to use ResolvedLogSourceConfiguration['fields'] rather than relying on the underlying, backing types.

[Kerry350]

@weltenwort Thanks for the review.

Out of curiosity, what brought you to this opinion?

I think it was mostly with regards to refactoring. I think when we type "our" concept (source config here) and use that, it makes it a lot easier to change things later. It can also make it a bit easier to reason about where things originate from and how they fit into things overall.

There are pros and cons though. This would arguably leak concepts and implementation details to layers where they shouldn't be.

Anyway, I wimped out regardless and kept with the DataViewField type and didn't make any changes 😅 These were mostly just things bouncing around my head as I was considering the two ideas / styles when untangling the types.

[kibanamachine]

💔 Backport failed

The backport operation could not be completed due to the following error:
There are no branches to backport to. Aborting.

The backport PRs will be merged automatically after passing CI.

To backport manually run:
node scripts/backport --pr 121108

[weltenwort]

Yes, that makes sense. We can introduce custom types when they start to diverge from the data view concepts.