LLC does not add api-version to LRO URI in `UpdateStatus()`

While working on the LLC for Question Answering authoring, @AhmedLeithy found that the api-version query parameter was not being added to the URI returned by the Operation-Location header. This was causing a 404 but, even if the service handled that, assuming the latest api-version could result in unexpected response models.

Talking with Jeff and Johan, an api-version in a Operation-Location is not required for LROs, so the client should add one if not already set (some services do pass the api-version back e.g., Key Vault).

On a related note, the nextLink model property for paged results should include an api-version, but it might be good to implement the same behavior described in this bug just to make sure we are consistent.

[fengzhou-msft]

The guidance should be the same: replace the version path segment with the version the client wants to use. How hard is this too implement?

The API version is set in the ClientOption when creating a Client, and all requests sent by the client would use that version except the LRO cases we discuss here. If I understand correctly, we need to either add the API version or replace it for the link returned from service for LRO. That would be a simple change from https://github.com/Azure/autorest.csharp/pull/1749.

[mikekistler]

@JeffreyRichter I do not see the logic here. This is completely contrary to Operation-Location being an “opaque absolute URL”. We are now asking users to crack apart the URL and add a query parameter before issuing the GET. At the very least this breaks with our previous guidance.

Can we please review this in the API Stewardship leadership team before we advise teams to go off and implement this guidance?