Odata: enhance nextLink unmarshal

[teowa]

try to resolves hashicorp/terraform-provider-azurerm#24948

Seems the error is because code-gen does not handle x-ms-pageable.nextLinkName

And the nextLink is used in

go-azure-sdk/sdk/client/client.go

Lines 538 to 579 in 8ee56b0

	func (c *Client) ExecutePaged(ctx context.Context, req *Request) (*Response, error) {
	// Perform the request
	resp, err := c.Execute(ctx, req)
	if err != nil {
	return resp, err
	}
	// Check for json content before handling pagination
	contentType := strings.ToLower(resp.Header.Get("Content-Type"))
	if !strings.HasPrefix(contentType, "application/json") {
	return resp, fmt.Errorf("unsupported content-type %q received, only application/json is supported for paged results", contentType)
	}
	// Unmarshal the response
	firstOdata, err := odata.FromResponse(resp.Response)
	if err != nil {
	return resp, err
	}
	if firstOdata == nil {
	// No results, return early
	return resp, nil
	}
	// Get results from this page
	firstValue, ok := firstOdata.Value.([]interface{})
	if !ok || firstValue == nil {
	// No more results on this page
	return resp, nil
	}
	// Get a Link for the next results page
	var nextLink *odata.Link
	if req.Pager == nil {
	nextLink = firstOdata.NextLink
	} else {
	nextLink, err = odata.NextLinkFromCustomPager(resp.Response, req.Pager)
	if err != nil {
	return resp, err
	}
	}
	if nextLink == nil {

This PR simply hardcode the nextLink to handle the case pageable List API returns next link through nextLink field instead of standard @odata.nextLink field.

A more robust solution is to make use of x-ms-pageable.nextLinkName for pageable List API at the generator-go-sdk , but it might break existing code struct.

[tombuildsstuff]

hey @teowa

Thanks for this PR.

I've taken a look through and left a comment inline, and whilst this approach will work for the default values for ARM, the nextLink value can come from one of a number of fields depending on the API in question - as such I believe it'd be better to fix this in hashicorp/pandora's generator-go-sdk tool, which has access to the name of the field containing the paginated value instead?

Thanks!

[tombuildsstuff]

There's a number of possible values for this field depending on the part of the API in question, so these two fields aren't necessarily sufficient.

Instead the SDK supports defining a custom pager which, given that Pandora has the JSONName for the field containing the pagination details, would allow us to output a CustomPager (like so) which is then configured on the client.RequestObject struct and ultimately used when the SDK method definition is output.

We're currently using this information to build out the AutoRest methods that use polling so once the CustomPoller is output, that should be all that's needed.

As such, rather than doing this here - can we update generator-go-sdk to output a CustomPoller as needed here instead, which'll fix this regardless of the field type?

[teowa]

Thanks @tombuildsstuff for reviewing this and providing helpful detailed advice, I have submitted hashicorp/pandora#3958 to solve the issue.