init: fix top-level module reloading

[wchargin]

Summary:
Fixes #1989 (also described in a new comment in __init__.py).

This will require a Google-internal sync change: http://cl/238144308.

Test Plan:
Regression test added. It fails before this change in Python 2 and 3,
and passes after this change in both as well. The http://cl/238144308
test plan also passes.

wchargin-branch: reload-tensorboard

[nfelt]

FWIW, one other potential way to address this would be for the lazy loading logic itself to check if the named module already exists in sys.modules, and if it does exist, just return that module immediately. This would mean that after reloading, the modules would be pre-resolved rather than lazy, so it's different from the approach here, but also seems correct. Thoughts?

[wchargin]

check if the named module already exists in sys.modules

Presuming that you mean the argument to lazy.lazy_load… this seems
like an opportunity for confusion/surprise. These names aren’t required
to correspond to actual modules at all: e.g., the tensorboard.compat
LazyModules have module-like names, but no such modules exist. For this
string to sometimes be used decoratively and sometimes be used
semantically would be an unnecessary inconsistency, imo. If it were to
always behave semantically, then that would be fine—but as of #1781
that is deliberately not the case.

[nfelt]

Fair enough. I think it is fair to require that the names passed to the decorator match the actual importable name of the decorated symbol, which is all that's really required for this to work (if there is no module in sys.modules, you fall back to the lazy function, regardless of whether there ever is such a module). But what you've done is fine too.

[wchargin]

if there is no module in sys.modules, you fall back to the lazy
function, regardless of whether there ever is such a module

Yep, understood. It only really breaks if you have a lazy_load("foo")
and a module foo but the lazy module loads a different module, which
seems like a bad idea all around.

I think it is fair to require that the names passed to the decorator
match the actual importable name of the decorated symbol, which is all
that's really required for this to work

This already doesn’t hold within Google, though. :-)