Fail safe operations on PATCH for L2VPN

[italovalcy]

Hi,

As discussed on this PR comment:

We need to provide means for having a Fail Safe L2VPN PATCH operation, meaning:

• When changing the L2VPN, we should provide means to validate the request before applying any changes to reduce user impact
• When failed to apply any changes, we should provide means to rollback the change
• We should safely save the request to the DB, so that we will have consistent data and preserve user request
• We should provide means to recover failed L2VPN

[YufengXin]

Plan to proceed in the following order:

First classify PATCH request in four categories depending on the fields to be changed, then the actions.

a. Annotation fields: name, description, notification, Scheduling

• Action: DB record update.
  b. QoS Metrics: BW, Latency, and Availability
• Action 1: If OXP API allows metric modification else
• Action 2: Reprovisioning
• or Not Supported
  c. endpoint vlans:
• Action: 1: If OXP API allows VLAN modification else
• Action 2: Reprovisioning
• or Not Supported
  d. endpoint ports:
• Reprovisioning,
• or Not supported

Policy:
a. Endpoints modification (ports and vlans) allowed? yes/no
b. Rollback to original request if patch fails? yes/no

@italovalcy @congwang09 @gretelliz Please review/revise/comment the plan