Two issues were found while debugging a strange issue encountered

locally with ClientCommChannel. When performing JavaScript test runs,

I was getting page stalls, with the dev server showing constant reloads

for other Review Board tabs. This was happening despite the fact that

the JavaScript tests should not be sending anything over a channel, and

the other pages should have ignored any such messages anyway.
Despite not finding the cause of that problem, two other issues were

found.
First, the unit tests were attempting to reset the static

ClientCommChannel.instance property after tests ran. This had two

problems:


We never actually closed the BroadcastChannel, leading to a leak

   that could cause events to be processed on the page.


When setting a static property of a Spina-wrapped class, we actually

   end up setting it on the wrapper and not the wrapped class. We'll

   need to think through this a bit, but for now, the rule is that only

   a class is able to manage its own static attributes.


A new ClientCommChannel.close() method has been added that takes care

of both problems.
Second, in theory, a reload message on a ClientCommChannel with a

null payload could cause Review Board pages aside from review request

pages to reload unnecessarily.
Reload handling uses page-specific data to determine if a reload request

from another tab applies to the current page. For review request pages,

this used the review request ID, which was generally fine since no other

pages sent this command over. However, if the command were to be issued

on any other page, resulting in null reload data, then all non-review

request pages would attempt a reload.
We now disallow any reload attempts if there's no page data to key

checks off of. This applies to both sending the reload message and

processing them, as a safety mechanism.

Unit tests pass, and the asserts weren't hit. Previously, adding asserts

around instance management showed that the instance could not be

reset.
Verified that no other Review Board pages were being activated when

force-sending a broadcast message with null page data, and that normally

sending this resulted in an error log.