Fixed a lock inversion issue with account

In updateRouteSubscriptionMap(), when a queue sub is added/removed,
the code locks the account and then the route to send the update.
However, when a route is accepted and the subs are sent, the
opposite (locking wise) occurs. The route is locked, then the account.

This lock inversion is possible because a route is registered (added
to the server's map) and then the subs are sent.

Use a special lock to protect the send, but don't hold the acc.mu
lock while getting the route's lock.

The tests that were created for the original missed queue updates
issue, namely TestClusterLeaksSubscriptions() and
TestQueueSubWeightOrderMultipleConnections() pass with this change.

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>

test/norace_test.go

@@ -380,6 +380,7 @@ func TestQueueSubWeightOrderMultipleConnections(t *testing.T) {
 	// we just want to make sure we always are increasing and that a previous update to
 	// a lesser queue weight is never delivered for this test.
 	maxExpected := 10000
+	updates := 0
 	for qw := 0; qw < maxExpected; {
 		buf := routeExpect(rsubRe)
 		matches := rsubRe.FindAllSubmatch(buf, -1)
@@ -397,6 +398,10 @@ func TestQueueSubWeightOrderMultipleConnections(t *testing.T) {
 				t.Fatalf("Was expecting increasing queue weight after %d, got %d", qw, nqw)
 			}
 			qw = nqw
+			updates++
 		}
 	}
+	if updates >= maxExpected {
+		t.Fatalf("Was not expecting all %v updates to be received", maxExpected)
+	}
 }