With the checkin of #10362, the code to render to a stream now looks like:

```
import { renderToStream } from 'react-dom/server'

renderToStream(<div>some text</div>).pipe(response);
```

This is great! I am, however, a little concerned about taking the word "node" out of the mix, because I'm thinking that we may eventually want to render to [**browser** streams](https://www.w3.org/TR/streams-api/), which are a really neat feature that can be used in concert with "service-worker-side rendering". I would propose renaming `renderToStream` to `renderToNodeStream` and `renderToStaticStream` to `renderToStaticNodeStream`.  This would give room for `renderToBrowserStream` in the future.

If I make a PR on this, would it have a chance of being accepted? 

cc @gaearon & @sebmarkbage 
'no unknown attributes for custom elements with null value',
        async render => {
          const e = await render(<custom-element foo={null} />);
          expect(e.hasAttribute('foo')).toBe(false);
        },
      );
      itRenders(
        'unknown attributes for custom elements using is',
        async render => {
          const e = await render(<div is="custom-element" foo="bar" />);
          expect(e.getAttribute('foo')).toBe('bar');
        },
      );
      itRenders(
        'no unknown attributes for custom elements using is with null value',
        async render => {
          const e = await render(<div is="custom-element" foo={null} />);
          expect(e.hasAttribute('foo')).toBe(false);
        },
      );
    });
    itRenders('no HTML events', async render => {
      const e = await render(<div onClick={() => {}} />);
      expect(e.getAttribute('onClick')).toBe(null);
      expect(e.getAttribute('onClick')).toBe(null);
      expect(e.getAttribute('click')).toBe(null);
    });
  });
  describe('elements and children', function() {
    function expectNode(node, type, value) {