Fix a bug where callbacks would see blips

When a new OemPreference object is set, the requests
tracking that default will be re-created to track the
new default. This is true regardless of whether that
particular default has changed.

Because the new copied request doesn't know about the
old satisfier, the rematch code will mistakenly think
this callback didn't have a network and will send a
spurious onAvailable to it.

This patch fixes this by simply copying the satisfier
together with the rest of the NRI. The matching code
will then understand the correct previous status.

As a drive-by fix, this also fixes the annotations on
the reassignment contents that can be null. They have
more complex interactions (not everything can be null
at the same time), but the old annotations were just
putting @NonNull on nullable stuff.
In the same line, while there used to be a case with
a satisfier but no request when the satisfier is the
no-service network, there may now be a case where the
old satisfier is known but the old request isn't.

Test: FrameworksNetTests
Test: TODO : need a unit test for this
Change-Id: Ide2567b226722ea9d35ebd8205943363e27647a2

0 files changed, 0 insertions, 0 deletions