discovery/syncer_test: fix benign off-by-one in DelayDOS test

Prior to this change, the numQueryResponses that we calculated would be
one more than what we actually wanted since it didn't account for the
initial QueryChannelRange msg. This resulted in the test sending one
extra delayed query than was configured. This doesn't fundamentally
impact the test, but does make what happens in the test more reflective
of the configuration.

discovery/syncer_test.go

@@ -1070,8 +1070,10 @@ func TestGossipSyncerDelayDOS(t *testing.T) {
 	numUndelayedQueries := syncer1.cfg.maxUndelayedQueryReplies
 
 	// We will send enough queries to exhaust the undelayed responses, and
-	// then send two more queries which should be delayed.
+	// then send two more queries which should be delayed. An additional one
-	numQueryResponses := numUndelayedQueries + numDelayedQueries
+	// is subtracted from the total since undelayed message will be consumed
+	// by the initial QueryChannelRange.
+	numQueryResponses := numUndelayedQueries + numDelayedQueries - 1
 
 	// The total number of responses must include the initial reply each
 	// syncer will make to QueryChannelRange.
@@ -1081,10 +1083,11 @@ func TestGossipSyncerDelayDOS(t *testing.T) {
 	// scaled by the chunk size being used.
 	numTotalChans := numQueryResponses * chunkSize
 
-	// Although both nodes are at the same height, they'll have a
+	// Construct enough channels so that all of the queries will have enough
-	// completely disjoint set of chan ID's that they know of.
+	// channels. Since syncer1 won't know of any channels, their sets are
+	// inherently disjoint.
 	var syncer2Chans []lnwire.ShortChannelID
-	for i := numTotalChans; i < numTotalChans+numTotalChans; i++ {
+	for i := 0; i < numTotalChans; i++ {
 		syncer2Chans = append(
 			syncer2Chans, lnwire.NewShortChanIDFromInt(uint64(i)),
 		)