fix(pollers/util.go): Handle missing JSON path gracefully by using entire payload

[yyoshiki41]

What

ResultHelper attempts to extract the value at the specified JSON path.
If the specified JSON path is not found in the response, the entire payload is used as the result.

Why

In #22980, JSON path extraction was introduced.
However, in Azure Document Intelligence that adopted Operation-Location header strategy, it is not included under the key payloadPath: "result". As a result, the correct output cannot be retrieved (always nil).

This fix updates the logic to use the entire response if the specified JSON path key does not exist.

Ref

• Azure Document Intelligence quickstart guide.

---

• The purpose of this PR is explained in this or a referenced issue.
• The PR does not update generated files.
  • These files are managed by the codegen framework at Azure/autorest.go.
• Tests are included and/or updated for code changes.
• Updates to module CHANGELOG.md are included.
• MIT license headers are included in each file.

[github-actions]

Thank you for your contribution @yyoshiki41! We will review the pull request and get back to you soon.

[yyoshiki41]

@microsoft-github-policy-service agree

[jhendrixMSFT]

@JeffreyRichter shouldn't the payload for the terminal success case always be under the result property in the status monitor JSON response? I thought that was the contract.

[yyoshiki41]

Reproduction Steps

After upgrading to github.com/Azure/azure-sdk-for-go/sdk/[email protected], result is always nil when executing the following pseudo code.

{
	endpoint := "endpoint"
	req, err := runtime.NewRequest(ctx, http.MethodPost, endpoint)
	if err != nil {
		return nil, err
	}
	if err := req.SetBody(&readSeekCloser{bytes.NewReader(body)}, "application/json"); err != nil {
		return nil, err
	}
	// Start pipeline
	pipeline := c.azure.Pipeline()
	resp, err := pipeline.Do(req)
	if err != nil {
		return nil, err
	}
	defer resp.Body.Close()

	if resp.StatusCode >= 400 {
		return nil, runtime.NewResponseError(resp)
	}

	// Poll until the operation is done
	options := &runtime.NewPollerOptions[AnalyzeResponse]{}
	poller, err := runtime.NewPoller(resp, pipeline, options)
	if err != nil {
		return nil, err
	}
	result, err := poller.PollUntilDone(ctx, &runtime.PollUntilDoneOptions{})
}

// AnalyzeResponse represents a response from the Analyze operation
type AnalyzeResponse struct {
	Status              string        `json:"status"`
	CreatedDateTime     time.Time     `json:"createdDateTime"`
	LastUpdatedDateTime time.Time     `json:"lastUpdatedDateTime"`
	AnalyzeResult       AnalyzeResult `json:"analyzeResult"`
}

[JeffreyRichter]

The guidelines are here: https://github.com/microsoft/api-guidelines/blob/vNext/azure/Guidelines.md#long-running-operations--jobs

We have 4 LRO patterns: PUT, DELETE, LRO Action on resource & LRO action not on a resource. Just the LRO action patterns have a result property and yes, this property should only be set/read when the status is "success".