[WIP] Spike test using shared libraries rather than static linking

[EricCousineau-TRI]

Relates #7294 / #6760:

This is a (semi-)quick test of having Drake use shared libraries, rather than rely on static linking, trying to skip waiting on bazelbuild/bazel#492, using one of the suggested workarounds.

Pros:

• Smaller files
  • On master, doing an install in debug mode yields libdrake.so of about 1.6GB (per Francois's findings)
  • With this branch, libdrake.so is about 2MB.
• Feels cleaner-ish

Cons:

• Fighting against Bazel:
  • linkshared causes any upstream libraries that have any bit of object code to be linked as Bazel-mangled shared objects. This sucks when working with externals, because I had to either have to shim them using (a) the workaround from 492, or (b) create a "barrier" library to intercept the
  • linkstatic seems to be catered to how a library is consumed, rather than produced. Maybe there's a better balance of linkstatic and linkshared that I missed.
• Speed when loading:
  • It took quite a while to try and import pydrake after installing.
  • Not sure what the load time for GDB would be.

I tested the installed libraries with the following command:

cd drake
mkdir -p build/install
bazel --bazelrc=/dev/null run //:install -- ~+/build/install
find build/install/lib -name 'libdrake*.so' | xargs -n 1 -P8 ldd | grep 'not found' | sort -u
# ^ Race conditions for `-P8` shouldn't matter too much

When running bazel --bazelrc=/dev/null test //..., all but 15 tests pass:

• All python tests (missing libdrake-automotive-maliput-dragway-dragway.so - could be fixed quickly?)
• Some linting
• rgbd_camera_test - Same things as what's in the FAQ, I believe.

I wouldn't say this is anywhere near ready for prime time, but an initial attempt.

\cc @jwnimmer-tri @jamiesnape @fbudin69500 @stonier

---

This change is 

[EricCousineau-TRI]

I tried to revamp this branch on upstream/master, and got the basics of Python working again.

I had previously thought that the slowdown for Python (loading the shared libraries?) only happened on install; however, it appears that it happens at development time as well.

Test commands:

# From Bazel.
bazel --bazelrc=/dev/null build //bindings/pydrake:common_test
time bazel --bazelrc=/dev/null run //bindings/pydrake:common_test
# From Install.
mkdir -p build_install && bazel --bazelrc=/dev/null run //:install -- ${PWD}/build_install > /dev/null
export PYTHONPATH=${PWD}/build_install/lib/python2.7/site-packages:${PYTHONPATH:-}
time python -c 'import pydrake'

Timing for master (be4f658):

real    0m0.475s
user    0m0.007s
sys     0m0.005s
---
real    0m0.046s
user    0m0.046s
sys     0m0.000s

Timing for this branch (decadd1):

real    0m3.566s   # YUCK
user    0m0.012s
sys 0m0.005s
---
real    0m3.795s
user    0m3.727s
sys 0m0.044s

If I just try a C++ binary (e.g. take resource_tool, but make it depend on drake_shared_library), and execute it after install:
On master, it takes about 0.02s
On this branch, it takes about 0.45s.

From my initial impression, we can either:
(a) use consolidated targets in development, only using granular targets when testing internally; externally, always use composite targets (be it libdrake.so, libdrake-common.so, etc.).
(b) figure out how to consolidate existing linkages for shared objects (like patchelf), or
(c) something else that I'm missing (profile dlopen for Python, see if that can be fixed?).

\cc @jamiesnape @jwnimmer-tri

[jwnimmer-tri]

@EricCousineau-TRI Do you still want to have this PR open?

[EricCousineau-TRI]

Eh, I'll end having to large rebase anywho and the open issue is tracking it just as well, so no.