[Network] `vnet-gateway vpn-client generate` workarounds

[tjprescott]

To implement #4249, two workarounds were needed.

1. The SDK implementation of these commands was duplicated in the CLI and referenced directly due to a bug in autorest that would not accept a 202 status code.

2. The service implementation sends both Azure-AsyncOperation and Location headers. The Async-Operation header is used for absolutely nothing, but the service wants you to poll on the Location header. msrestazure is designed such that if both are present, Azure-AsyncOperation takes precedence as it is an optional header. Removal of the Azure-AsyncOperation header by the service would remove the need for this workaround.

   cc/ @lmazuel, @aanandr

[lmazuel]

@tjprescott Note that the latest email thread said that the correct behavior is to poll using Azure-AsyncOperation, and when it's complete to do a final GET with the Location header of the first answer. So correct workaround should be:

• Do initial request, save Location header
• Poll as usual (Azure-AsyncOperation)
• Force should_i_do_final_get to do it against the saved Location

[tjprescott]

@lmazuel does this warrant changes at the msrestazure level?

[lmazuel]

Let's say I need to make AzureOperationPoller more flexible to spooky restapi :)

[tjprescott]

@lmazuel I believe changes have been made to msrest that I can remove the CLI workarounds and close this issue. Is this the case???

[tjprescott]

My PR fixes the mock dependencies, but there are still problems with the generatevpnclientpackage Swagger that means I cannot remove the CLI's other workaround.

[tjprescott]

@lmazuel for the updates to Swagger on this guy.

generatevpnclientpackage needs the final location updated and needs to accept 202 code generate_vpn_profile needs the final location updated

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc

[yonzhan]

add to S165.