…ing bigquery/gcs and all its dependencies.

I realize this change is pretty confusing and took me a while to get to a working state, so feel free to comment, ask for clarifications. I'll try to explain what it's doing but let me know if it's not clear.

This tries to use import hooks (as suggested by Vincent, thanks!) to do the monkeypatching at module load time (versus when sitecustomize is loaded prior to user code execution). This resolves the issue of having tons of modules (google.cloud.* and all its deps) loaded for Kernels that may never use bigquery/gcs. The strategy is: setup an import hook that checks when one of our special libraries is being loaded and instead of loading the one in the module path, load our monkeypatched one.

The issue is, our monkeypatching uses kaggle_gcp which itself loads google.cloud.bigquery (it has to, since we do the monkeypatching by subclassing bigquery), which causes a circular dependency/recursive imports. We get around this by adding a check in the module finder hook to return the actual bigquery library if the call stack originates from kaggle_gcp, thus avoiding the circular dependency. We still have the issue that if the user (or test code) calls import kaggle_gcp before from google.cloud import bigquery, we will load the true bigquery library during the kaggle_gcp load and never end up monkeypatching it since google.cloud.bigquery will already have been loaded. To solve this, I add a init() to the end of kaggle_gcp so if ever kaggle_gcp is imported, then the monkeypatching will guaranteed to be done even after the true bigquery library has been loaded.