This will also solve issues related to DN restart and NN may not process the block report.
True, but the boolean patch (simple incremental improvement on the existing trunk behavior) fixes both DN restart and reregistration after a broken connection. The NN cannot distinguish the two. So with a boolean, the NN (naively) processes the BR associated with every (re)registration.
A sequence number, that relies on a sentinel value, allows the DN to dictate the NN's behavior. This works well for restart since we know we are starting from 0. For a rereg, block updates may have been lost, so the sequence number must be guaranteed to always be reset to 0. That's naive like the boolean, and might be hard or fragile to ensure it's always reset - in which case we might as well go with the boolean.
Better yet, the logic would be to (seqNum == 0 || seqNum != lastSeqNum). However this requires writable/RPC changes on 23, and protobuf changes on trunk/2 and trying to ensure backwards compatibility with an optional protobuf field, etc. Would you be ok if I filed another jira?