[Reporting] standardize internal config passing to use a simple object

[tsullivan]

Summary

Remove a complex type of object that was used to pass around config settings, that was in place to follow code patterns from the old Kibana platform.

Addresses https://github.com/elastic/kibana/pull/155081/files#r1188025616

Checklist

• Unit or functional tests were updated or added to match the most common scenarios
• Ensure hostname 0.0.0.0 is re-written to localhost and warning logs are working correctly

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

Risk	Probability	Severity	Mitigation/Notes
Regression in xpack.reporting.kibanaServer yml settings	Low	Med	Reporting sometimes needs a URL to the Kibana server. The necessary protocol/hostname/port needed build the URL is sourced from kibana.yml settings under server.*, but can be overridden using settings in xpack.reporting.kibanaServer. This feature exists because the headless Chromium browser sometimes must connect to a proxy that Kibana otherwise doesn't know about.

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[rshen91]

Looking at the test failure - it seems that the API_BASE_URL in x-pack/plugins/reporting/common/constants/index.ts has a leading '/' - is it ok to just update the test?

I'm not sure why that wasn't failing before these changes. 🤔

[rshen91]

I like that we're able to remove the level of abstraction of the kbnConfig and ReportingConfigType. Thank you for going through these changes 🙇🏻

I think the test failure can just be changed? I tested it and didn't see it affecting other tests by adding the leading slash but also was hesitant to push my changes onto this branch - I might try some roundabout PR request onto this for my own learning :face_palm:

[tsullivan]

Looking at the test failure - it seems that the API_BASE_URL in x-pack/plugins/reporting/common/constants/index.ts has a leading '/' - is it ok to just update the test?

Yes, I also think that's the best way to move forward. 👍🏻

I'm not sure why that wasn't failing before these changes. 🤔

I think there was something wrong about the HTTP mocks used in reporting tests in the previous code. Somehow I fixed it, and now the tests a mistake that was in the previous code.

Unfortunately, I didn't catch this before filing this PR - which I usually try to do.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 78ed270

Metrics [docs]

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	19	21	+2
securitySolution	400	404	+4
total			+6

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	20	22	+2
securitySolution	480	484	+4
total			+6

History

• 💚 Build #126708 succeeded 2f3abfd
• 💔 Build #126681 failed e1092dc
• 💚 Build #126652 succeeded 59798eb
• 💔 Build #126438 failed 096531e

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

[sebelga]

LGTM 👍

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)