**Do you want to request a *feature* or report a *bug*?**

Bug

**What is the current behavior?**

If you remove the ref from a mounted HostComponent on an update, it calls the original ref with null. If you remove the ref from a mounted ClassComponent on an update, it does *not* call the original ref with null.


https://codesandbox.io/s/q8k7776pz9 Note that it doesn't call ref1 (passed to FooInner as ref) with null

https://codesandbox.io/s/849538y8m8 Note that it **does** call ref1 (passed to div as ref) with null

If you *modify* the ref from either a HostComponent or a ClassComponent (change from `ref={this.ref1}` to `ref={this.ref2}`), the original ref (ref1) is called with null and the new ref (ref2) is called with the instance.

(take the sandboxes above and change the second `<Foo>` to `ref={this.ref2}`

**What is the expected behavior?**

Honestly not sure but it should be consistent. The reason this is different is because for HostComponents, [we decide to schedule a Ref effect on completeWork](https://github.com/facebook/react/blob/87ae211ccd8d61796cfdef138d1e12fb7a74f85d/packages/react-reconciler/src/ReactFiberCompleteWork.js#L464-L466) as long as `current.ref !== workInProgress.ref`. For ClassComponents, [this decision is made on beginWork ](https://github.com/facebook/react/blob/87ae211ccd8d61796cfdef138d1e12fb7a74f85d/packages/react-reconciler/src/ReactFiberBeginWork.js#L184-L188) as long as `workInProgress.ref && (!current || current.ref !== workInProgress.ref)` -- which means if workInProgress.ref is null, the behavior is different (hence this issue). 

We should probably pick one and make it consistent. 

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

Unsure - it for sure is an issue in latest/Fiber, but I haven't dug deep enough to see what happened in <16.
renderExpirationTime: ExpirationTime,
  ) {
    
    switch (workInProgress.tag) {
      case ClassComponent:
        pushLegacyContextProvider(workInProgress);
        break;
      case HostRoot:
        pushHostRootContext(workInProgress);
        break;
      default:
        invariant(
          false,
          'Invalid type of work. This error is likely caused by a bug in React. ' +
            'Please file an issue.',
        );
    }
    // Add an error effect so we can handle the error during the commit phase
    workInProgress.effectTag |= Err;
    // This is a weird case where we do "resume" work — work that failed on
    // our first attempt. Because we no longer have a notion of "progressed
    // deletions," reset the child to the current child to make sure we delete
    // it again. TODO: Find a better way to handle this, perhaps during a more
    // general overhaul of error handling.
    if (current === null) {
      workInProgress.child = null;
    } else if (workInProgress.child !== current.child) {
      workInProgress.child = current.child;
    }
    if (