[FEATURE] Improve robustness of WorkflowNode parsing of User Inputs

[dbwiddis]

Is your feature request related to a problem?

Parsing of Workflow Nodes (steps) assumes that JSON objects are key-value maps unless specifically coded otherwise:

flow-framework/src/main/java/org/opensearch/flowframework/model/WorkflowNode.java

Lines 163 to 180 in 51e229c

	case START_OBJECT:
	if (GUARDRAILS_FIELD.equals(inputFieldName)) {
	userInputs.put(inputFieldName, Guardrails.parse(parser));
	break;
	} else if (CONFIGURATIONS.equals(inputFieldName)) {
	Map<String, Object> configurationsMap = parser.map();
	try {
	String configurationsString = ParseUtils.parseArbitraryStringToObjectMapToString(configurationsMap);
	userInputs.put(inputFieldName, configurationsString);
	} catch (Exception ex) {
	String errorMessage = "Failed to parse" + inputFieldName + "map";
	logger.error(errorMessage, ex);
	throw new FlowFrameworkException(errorMessage, RestStatus.BAD_REQUEST);
	}
	break;
	} else {
	userInputs.put(inputFieldName, parseStringToStringMap(parser));
	}

This is brittle and can lead to failure if a new feature/API is added which includes a more complex nested object. As more workflow steps are created, the chances of more custom objects increases.

What solution would you like?

Add a processing layer in between encountering the start of an object and reading the map:

• Start building a new object with a new XContent Builder
• Process tokens, copying them over into the new builder until the corresponding END_OBJECT is reached
• Build the object
• Send the entire (new) XContent object to the existing map parsing method
• Catch a parsing exception creating the map; on exception, simply place a String value (containing the JSON form of the object) into the map for that key. Alternately, just ignore that value (or place null in the map) since in any case, if the step doesn't include that as a required or optional input, it's not even going to be evaluated. In either case, log the parsing exception.

What alternatives have you considered?

We can also try to parse multiple layers of maps, but would need to protect against arbitrary levels of recursion. This is essentially what's done by other JSON parsers such as GSON, but we decided early on to use XContent parsing.

Do you have any additional context?

In addition to robustness in parsing, we need to set up a way to test against all implemented APIs (steps) using their specifications, to catch API changes early.