[MetricsAdvisor] Design: how Update methods should be designed

[kinelski]

Current approach has multiple flaws.

• It takes an ID both as a method parameter and as a model property. For instance, UpdateHook takes a hookId parameter and a NotificationHook instance, which contains an Id property. Should we make Id settable and remove the string parameter?
• .NET cannot differentiate between null and undefined. This is likely the main cause of [MetricsAdvisor] Fix Update sample issues #16168. One of the following scenarios will happen unintentionally:
  • User wants to update a property to null (clear it). However, our client doesn't send anything.
  • User doesn't want to change property. However, our client will send a null and clear it.
• We use the same model for Create and Update methods. However, some properties are immutable after creation, so they are not used during update. Also, Update does not have required properties, so we shouldn't enforce them in the constructor (but we need to do so for Create).

[kinelski]

We'll only support the scenario of calling Get followed by Update. Update methods will take the whole object, with no ID parameter. Changes already implemented and merged to master.