commit 3949eea76e8cf0fd57c1b00014494fdfbc91a248
author Dave Borowitz <dborowitz@google.com> Wed Jan 30 12:13:22 2019 -0800
committer Dave Borowitz <dborowitz@google.com> Fri Feb 08 08:55:27 2019 -0800
tree 438572f86bf4b43f2dadac2947f0a0e1ab1633e3
parent a9fc40ccdc318ca24ba848716c70de45001f18d5

Refactor NotifyUtil analogously to AccountResolver

NotifyUtil#resolveAccounts was basically a wrapper around
AccountResolver. Give the class a new name, NotifyResolver, and have it
resolve inputs to a Result type. This Result type encapsulates both the
NotifyHandling enum and the ListMultimap that got passed around
everywhere. This has several significant advantages.

First, this pair of objects is used in many places, so cutting down two
arguments (including the unwieldy ListMultimap type) to one is a win on
its own. This change fixes some such methods, and the rest will be fixed
in future cleanups.

Second and more subtly, this change results in more explicit and less
error-prone behavior when a null notify field is passed in a REST API
object. Callers have to explicitly specify a non-null NotifyHandling
input to NotifyResolver#resolve, which typically means they have to do a
firstNonNull(input.notify, <some default>). It turns out that in the
REST API docs, there are several different defaults for the different
*Input types, including some that have different behavior for WIP/ready
changes. The documentation is structured per Input type, which means
it's always clear from the documentation what the default should be if
you have in front of you a FooInput. In other words, this pattern makes
it easier to inspect the code for correctness.

Change-Id: I609674d22b6a16b8fac32aeea1a57d293ee601d5