hparams: account for proto nondeterminism in tests

[wchargin]

Summary:
This test seems to be fine in open-source land, but failed 18/32 times
within Google, because the wire format order for maps is undefined:
https://developers.google.com/protocol-buffers/docs/proto3#maps

Test Plan:
Within google3, cherry-pick this patch onto http://cl/247655537, then
run :summary_v2_notf_test with --runs_per_test=128 to check for
flakiness.

wchargin-branch: hparams-test-deflake

[stephanwlee]

Honest question: does self.assertProtoEquals solve the issue?

[wchargin]

Nope. The protos (summary_1 and summary_2) are genuinely different,
but only insofar as the ....content fields are bytestrings that
contain different wire format representations of the same logical
object. Here’s the error (from my comment on the linked CL):

AssertionError: value {
  tag: "_hparams_/session_start_info"
  metadata {
    plugin_data {
      plugin_name: "hparams"
      content: "\032|\n\023\n\toptimizer\022\006\032\004adam\n\032\n\rlearning_rate\022\t\021{\024\256G\341z\224?\"@582419390b277d40968d8485643f1f8b22bb547061539ecf176b28630acfe4be)\315\314\314\314\314\334^@"
    }
  }
}
 != value {
  tag: "_hparams_/session_start_info"
  metadata {
    plugin_data {
      plugin_name: "hparams"
      content: "\032|\n\032\n\rlearning_rate\022\t\021{\024\256G\341z\224?\n\023\n\toptimizer\022\006\032\004adam\"@582419390b277d40968d8485643f1f8b22bb547061539ecf176b28630acfe4be)\315\314\314\314\314\334^@"
    }
  }
}

Using assertProtoEquals would give a nicer error message, but it
wouldn’t consider two distinct bytestrings as equal.

[stephanwlee]

Ah of course the content is serialized proto bytestring. I missed that bit. Thanks