Make scripting media type parsing more flexible

[pgomulka]

#65500 introduced a change to content_type field used in scripting. For JSON it required application/json; charset=UTF-8 but now the space was removed and lowercase param value is required.
This PR is making content_type field more flexible. Allowing spaces and is case insensitive for param values.
The parsing logic is reusing Content-Type and Accept header parsing

relates #65500

test failure:
closes #66986

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[pgomulka]

#65500 also accidentally broke the CI by a change in CustomMustacheFactory
old:
JSON_MIME_TYPE_WITH_CHARSET = "application/json; charset=UTF-8";
new:
JSON_MIME_TYPE_WITH_CHARSET = "application/json;charset=utf-8";
The template was stored in old cluster with old value, but read in upgraded cluster expecting the new value. Because the comparison was done on string equality it failed.
With this PR and use of ParsedMediaType the content_type parsing is more flexible

I am however still worrying about the scenario where a cluster is in a mixed state.
The new template is created with new content type and that request is sent to a v7 node which do not know about it.
Another scenario would be where a new template with new content type is sent to a v8 node, but cluster state propagates this to an old node which do not know about this value. I imagine the Script#writeTo should be updated for this..

[rjernst]

/cc @martijnvg

[jdconrad]

@pgomulka The situation you're describing is backwards-incompatible. Unless I'm misunderstanding we need to deprecate the old mime type and replace it with the new one over two versions. If we don't handle this scenario users may get stuck during upgrade when using stored mustache scripts (templates).

Edit: Spoke with @pgomulka and it was my misunderstanding. We just need to ensure we only write the older format to nodes that do not support the newer ones as he stated in his previous comment.

[pgomulka]

actually do you think it would be easier if we simply deprecate application/json;charset=utf-8 in ES7 and not allow it anymore in ES8 for new script templates?

we would only allow charset=utf-8 to be used in template if the template was created in ES 7.
I think the code would be simpler

[pgomulka]

I am closing this in favour of more simple approach #67677