[Maps] Fix proxy handling issues

[kindsun]

Resolves #67593. There were a few things preventing EMS proxies from functioning correctly:

• URL construction in maps/public/meta.ts used relative paths which resolved to the incorrect final URL. They also lacked a prepended basepath which is necessary for them to work correctly in a dev environment although they might work fine in production.
• The xpack.maps config was being passed to routes but they require values from the maps_legacy (map) config. This is admittedly confusing (related [Maps] Decouple maps and maps_legacy config dependencies #64810)
• Added validation for several routes. This isn't always necessary unless the logic in the route handler leverages query or params vars or alternatively some validation exists but different params/queries are passed. We had a couple of routes involved in proxying that met these criteria.
• Also did some minor cleanup while in routes. We had some residual logic testing for the presence of params, etc. Validation already covers this.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: ef74ff0

Build metrics

✅ unchanged

History

• 💔 Build #60510 failed 7d1b695
• 💔 Build #60371 failed e0eec47
• 💔 Build #60029 failed d1be94b

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

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[jsanz]

checked out locally and tested both with and without the proxy enabled and everything seems to work fine on the functional side 👍

[nickpeihl]

lgtm. code review and tested in firefox

[nickpeihl]

nit, but up to you really. we repeat some of these schemas such as elastic_tile_service_tos: schema.maybe(schema.string()), several times in this file. would it be feasible and easy to avoid duplicating these schemas?

[kindsun]

Yeah, I know what you mean, it does get a little repetitive. As far as I can tell, there's not an easy way to create reusable validation that we can also build upon (i.e.- add more validation where needed) unless we use a custom validator that does some base validation such as checking elastic_tile_service_tos: schema.maybe(schema.string()) etc. before doing any additional validation required by the calling route. tbh I'm still not sure that's the right path either so kicking that can down the road for now to get this fix in.