IPC pipes are not always connected:
- in case of a crashed renderer process before it gets respawned
- in case of a not-yet-spawned renderer process (example: tab discarding and session restore)

A few weeks ago sending an IPC to such a pipe would accumulate the IPCs (leading to leaks like issue 813045).  This is slowly changing:
- after r562491 IPCs sent to a crashed renderer are discarded instead
- we plan to discard IPCs sent to a not-yet-spawned renderer (to finish fixing issue 813045)

To prevent leaks (and accidental (*) discarding of IPCs after more CLs for issue 813045 land) we should consider some extra code tweaks - let's use this bug to track them.  Some ideas:
- Return null from RenderFrameHost::GetRemoteInterfaces (and GetRemoteAssociatedInterfaces)
- Return null from RenderProcessHost::GetRendererInterface
- Tweak RenderProcessHostImpl::BindInterface to return early if |is_dead_| (to account for races when binding is posted/initiated from non-UI thread) and otherwise DCHECK(is_initialized_) and DCHECK(child_connection_).

This bug will become more important as more CLs for issue 813045 land.  Some earlier discussion about null-vs-unbound can be found here: https://groups.google.com/a/chromium.org/d/topic/chromium-mojo/liRmqnqcDkg/discussion

(*) I am assuming that there no accidental discarding of IPCs is happening today and/or after more CLs for issue 813045 land:
- The trybots are green
- The handful of IPCs that are sent to a disconnected pipe seem okay to be discarded (e.g. network status updates)
OTOH, it is difficult to evaluate if mojo interfaces bound outside of //content are rebound when a crashed renderer process is respawned.