.updateWith() should only be callable if event was canceled

[marcoscaceres]

The way the spec is currently written, the payment sheet of a browser can lock up waiting on ev.updateWith() to be called.

What actually needs to happen is:

1. That the developer needs to cancel the event somehow and then call ev.updateWith() - maybe .updateWith() cancels the event automatically? (I like this, because it means existing apps can continue to work without devs needing to make any changes to their existing code! And browsers need only make a small change.)
2. the browser needs to check if the event was cancelled. If yes, wait for .updateWith(). If no, reuse the existing data (or present whatever data the user has changed - like a new address or shipping option). Payment sheets already do this when changing credit cards, email, phone number, for instance (where no event is fired at the page).

So, Proposal:

• Calling updateWith() sets the event's cancel flag.
• In the sheet:
  • If the event was not cancelled, then just update reusing the existing data + whatever new data the user provide/changed.
• Otherwise, wait for .updateWith()'s promise to settle.

Pre-empting discussion: checking if an event listener/handler is set on the payment request would violate the DOM spec (because it would be a side-effect). That would be very bad.

[marcoscaceres]

Might not need to deal with cancel flag at all, because we have [[waitForUpdate]].