[testHarnes/uiSettings] create stub uiSettings client with actual state

[spalger]

Rather than create the UiSettings client in the test harness, embed the logic in the client itself so that we can persist a little bit of state like observers and defaults.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[kimjoar]

Not sure I'm following why this is needed. Generally I'm not a fan of putting test code within production code unless there's a really good reason. If this is simplifying tests or something like that, it would be great to include those changes in this PR.

[spalger]

I guess it's mostly a precautionary measure for PRs like #17581.

That PR will be the first to utilize the new non-angular uiSettings client, and I'm mostly just worried about the way that the client will interact with mutations coming from the tests.

@ppisljar I'm not going to try to get this PR merged, but if you run into weird state issues when trying to test the new field formats registry, ping me and we can see if the changes in this PR help out.

[spalger]

Also, @tsullivan @sqren if you guys see weird caching/state issues in your browser tests that seem connected to the uiSettings client, please ping me so we can see if this helps.

[kimjoar]

Ah, I see 👍 I’m not against this if it makes tests less flaky. If we end up merging this it would be great with a comment on the code that explains why it’s put with the production code.