Fix LRO PATCH and simplification

[amarzavery]

This PR #875 fixed LRO PATCH in node.js and also simplified it. Similar changes need to be made in C#, Java, Ruby, Python so that every language is consistent.

[tbombach]

Thanks for opening this. I'm working on the C# changes

[annatisch]

@amarzavery - are you able to clarify how PATCH operations were fixed? I'm having trouble finding it amongst the refactor changes in the PR diff....

[amarzavery]

@annatisch - sure.

Previously implemented long running PATCH was incorrectly giving preference to provisioning state value.

For a PATCH, the resource has to be successfully created as a prerequisite. Hence, its provisioning state will always be succeeded. We were checking that and would return without polling.

The right thing to do for a PATCH operation is to look for Azure Async Operation Header and Location Header in the initial response. If they are present then we should poll (get) on the link provided in those headers until a terminal state is reached.

We were doing this kind of polling for long running POST and DELETE. Hence, we modified the logic for PATCH to not look for provisioning state and do the right thing.

As a part of this modification we realized that everything can be simplified into one method named getLongRunningOperationStatus() (by checking the initial method and the statuscode) rather than having the previous two methods (getPutOrPatch.., getPostOrDelete..). Hence this was reduced to one.

We still kept the old methods for backwards compatibility. These methods internally call the new method.

Hope this helps :).

[vishrutshah]

Removing Ruby Label as the Fix is in.

[annatisch]

@amarzavery, thanks so much - that helped lots!!
I think I've finally got this resolved for Python - I'd appreciate it if you could take a quick glance over my latest PR.

[jianghaolu]

(Not for Java runtime GA as this won't be a breaking change. Will fix it later.)