[pkg/ottl] Add ParseJSON factory function

[TylerHelmuth]

Description:
Adds a new factory function that can parse json strings into pcommon.Map types.

Link to tracking Issue:
Related to #9410
Related to #14938

Testing:
Unit tests

Documentation:
Added new function doc

[bogdandrutu]

I like the syntax, would like @djaglowski opinion on this.

[djaglowski]

I think the syntax looks really nice for json, but I'm concerned it may not extend to other formats.

Comparing to the parsers in pkg/stanza, I think nearly all would need at least one additional parameter.

• regex requires a regular expression
• csv requires headers
• keyvalue requires delimiter(s)
• syslog requires a protocol (arguably these could enumerate as separate formats, but there are other options for each format as well)

Of course we could have separate functions for these cases, but if that's necessary then I'm wondering how generalizable this signature will be. One other parser from pkg/stanza that could work with this signature is uri - so there are at least two. Do you have any others in mind that would use this function signature?

[bogdandrutu]

@djaglowski what about we have a variant argument at the end?

[TylerHelmuth]

@djaglowski thats good perspective. I don't love the idea of trying to make a generic parser and then having to have specific parsers anyways because they require more input parameters.

I think the formats that would fit this signature would be json, uri, yaml, and toml so we could get at least 4 out of this type of function.

From an end user perspective, though, I think it is better if we are consistent with 1 strategy; I don't want users to have to know that some types of parsing are lumped into this function and others are their own functions.

If there is a common characteristic that connects json, uri, yaml, and toml that can be included in the name of this function, then I'd feel better about combining them. If csv is a specific structure that warrents a ParseCSVIntoMap, then maybe json, uri, yaml, and toml are all grouped by something like ParseStructureIntoMap?

[TylerHelmuth]

@bogdandrutu we removed variadic support when support for explicit lists was added which I still support. I'm in favor of the language being explicit both in the function names and their parameters and variadic support breaks that.

[TylerHelmuth]

@kentquirk @evan-bradley what do you think?

[kentquirk]

I don't see a plausible, nameable map format that someone will realistically stick into a single field other than JSON, which kind of occurs naturally, especially in JS environments. Attaching YAML or TOML is so fraught with danger, that doesn't seem plausible. KV pairs or something you could parse with regexp possible but there's no named standard you could trust, so it needs a separate function.

I'd be in favor of dropping the format argument and renaming this to ParseJSONObject.

[evan-bradley]

Based on the discussion so far, I would agree that we should have a separate factory function for each format.

[TylerHelmuth]

Ok based on this discussion and the precedence set by Stanza I'll update this function to be JSON specific

[TylerHelmuth]

@djaglowski @evan-bradley @bogdandrutu @kentquirk ready for re-review.