SPARK-4445, Don't display storage level in toDebugString unless RDD is persisted.

Author: Prashant Sharma <prashant.s@imaginea.com>

Closes #3310 from ScrapCodes/SPARK-4445/rddDebugStringFix and squashes the following commits:

4e57c52 [Prashant Sharma] SPARK-4445, Don't display storage level in toDebugString unless RDD is persisted
SPARK-2811 upgrade algebird to 0.8.1

Author: Adam Pingel <adam@axle-lang.org>

Closes #3282 from adampingel/master and squashes the following commits:

70c8d3c [Adam Pingel] relocate the algebird example back to example/src
7a9d8be [Adam Pingel] SPARK-2811 upgrade algebird to 0.8.1
[SPARK-4444] Drop VD type parameter from EdgeRDD

Due to vertex attribute caching, EdgeRDD previously took two type parameters: ED and VD. However, this is an implementation detail that should not be exposed in the interface, so this PR drops the VD type parameter.

This requires removing the `filter` method from the EdgeRDD interface, because it depends on vertex attribute caching.

Author: Ankur Dave <ankurdave@gmail.com>

Closes #3303 from ankurdave/edgerdd-drop-tparam and squashes the following commits:

38dca9b [Ankur Dave] Leave EdgeRDD.fromEdges public
fafeb51 [Ankur Dave] Drop VD type parameter from EdgeRDD
Revert "[SPARK-4075] [Deploy] Jar url validation is not enough for Jar file"

This reverts commit 098f83c7ccd7dad9f9228596da69fe5f55711a52.
[DOCS][SQL] Fix broken link to Row class scaladoc

Author: Andy Konwinski <andykonwinski@gmail.com>

Closes #3323 from andyk/patch-2 and squashes the following commits:

4699fdc [Andy Konwinski] Fix broken link to Row class scaladoc
[SPARK-4180] [Core] Prevent creation of multiple active SparkContexts

This patch adds error-detection logic to throw an exception when attempting to create multiple active SparkContexts in the same JVM, since this is currently unsupported and has been known to cause confusing behavior (see SPARK-2243 for more details).

**The solution implemented here is only a partial fix.**  A complete fix would have the following properties:

1. Only one SparkContext may ever be under construction at any given time.
2. Once a SparkContext has been successfully constructed, any subsequent construction attempts should fail until the active SparkContext is stopped.
3. If the SparkContext constructor throws an exception, then all resources created in the constructor should be cleaned up (SPARK-4194).
4. If a user attempts to create a SparkContext but the creation fails, then the user should be able to create new SparkContexts.

This PR only provides 2) and 4); we should be able to provide all of these properties, but the correct fix will involve larger changes to SparkContext's construction / initialization, so we'll target it for a different Spark release.

### The correct solution:

I think that the correct way to do this would be to move the construction of SparkContext's dependencies into a static method in the SparkContext companion object.  Specifically, we could make the default SparkContext constructor `private` and change it to accept a `SparkContextDependencies` object that contains all of SparkContext's dependencies (e.g. DAGScheduler, ContextCleaner, etc.).  Secondary constructors could call a method on the SparkContext companion object to create the `SparkContextDependencies` and pass the result to the primary SparkContext constructor.  For example:

```scala
class SparkContext private (deps: SparkContextDependencies) {
  def this(conf: SparkConf) {
    this(SparkContext.getDeps(conf))
  }
}

object SparkContext(
  private[spark] def getDeps(conf: SparkConf): SparkContextDependencies = synchronized {
    if (anotherSparkContextIsActive) { throw Exception(...) }
    var dagScheduler: DAGScheduler = null
    try {
        dagScheduler = new DAGScheduler(...)
        [...]
    } catch {
      case e: Exception =>
         Option(dagScheduler).foreach(_.stop())
          [...]
    }
    SparkContextDependencies(dagScheduler, ....)
  }
}
```

This gives us mutual exclusion and ensures that any resources created during the failed SparkContext initialization are properly cleaned up.

This indirection is necessary to maintain binary compatibility.  In retrospect, it would have been nice if SparkContext had no private constructors and could only be created through builder / factory methods on its companion object, since this buys us lots of flexibility and makes dependency injection easier.

### Alternative solutions:

As an alternative solution, we could refactor SparkContext's primary constructor to perform all object creation in a giant `try-finally` block.  Unfortunately, this will require us to turn a bunch of `vals` into `vars` so that they can be assigned from the `try` block.  If we still want `vals`, we could wrap each `val` in its own `try` block (since the try block can return a value), but this will lead to extremely messy code and won't guard against the introduction of future code which doesn't properly handle failures.

The more complex approach outlined above gives us some nice dependency injection benefits, so I think that might be preferable to a `var`-ification.

### This PR's solution:

- At the start of the constructor, check whether some other SparkContext is active; if so, throw an exception.
- If another SparkContext might be under construction (or has thrown an exception during construction), allow the new SparkContext to begin construction but log a warning (since resources might have been leaked from a failed creation attempt).
- At the end of the SparkContext constructor, check whether some other SparkContext constructor has raced and successfully created an active context.  If so, throw an exception.

This guarantees that no two SparkContexts will ever be active and exposed to users (since we check at the very end of the constructor).  If two threads race to construct SparkContexts, then one of them will win and another will throw an exception.

This exception can be turned into a warning by setting `spark.driver.allowMultipleContexts = true`.  The exception is disabled in unit tests, since there are some suites (such as Hive) that may require more significant refactoring to clean up their SparkContexts.  I've made a few changes to other suites' test fixtures to properly clean up SparkContexts so that the unit test logs contain fewer warnings.

Author: Josh Rosen <joshrosen@databricks.com>

Closes #3121 from JoshRosen/SPARK-4180 and squashes the following commits:

23c7123 [Josh Rosen] Merge remote-tracking branch 'origin/master' into SPARK-4180
d38251b [Josh Rosen] Address latest round of feedback.
c0987d3 [Josh Rosen] Accept boolean instead of SparkConf in methods.
85a424a [Josh Rosen] Incorporate more review feedback.
372d0d3 [Josh Rosen] Merge remote-tracking branch 'origin/master' into SPARK-4180
f5bb78c [Josh Rosen] Update mvn build, too.
d809cb4 [Josh Rosen] Improve handling of failed SparkContext creation attempts.
79a7e6f [Josh Rosen] Fix commented out test
a1cba65 [Josh Rosen] Merge remote-tracking branch 'origin/master' into SPARK-4180
7ba6db8 [Josh Rosen] Add utility to set system properties in tests.
4629d5c [Josh Rosen] Set spark.driver.allowMultipleContexts=true in tests.
ed17e14 [Josh Rosen] Address review feedback; expose hack workaround for existing unit tests.
1c66070 [Josh Rosen] Merge remote-tracking branch 'origin/master' into SPARK-4180
06c5c54 [Josh Rosen] Add / improve SparkContext cleanup in streaming BasicOperationsSuite
d0437eb [Josh Rosen] StreamingContext.stop() should stop SparkContext even if StreamingContext has not been started yet.
c4d35a2 [Josh Rosen] Log long form of creation site to aid debugging.
918e878 [Josh Rosen] Document "one SparkContext per JVM" limitation.
afaa7e3 [Josh Rosen] [SPARK-4180] Prevent creations of multiple active SparkContexts.
Rework the "hadoop-provided" profile, add new ones.

The "hadoop-provided" profile should only apply during packaging,
since, for example, "spark-core" should still have a compile-time
dependency on hadoop since it exposes hadoop types in its API. So
reorganize the dependencies a bit so that the scopes are overridden
in the packaging targets. Also, a lot of the dependencies packaged
in the examples/ assembly are already provided by the main assembly,
so clean those up.

Also, add similar profiles for hive, parquet, flume and hbase (the
last two just used by the examples/ code, although the flume one
could also potentially be used by user's poms when packaging the
flume backend).

This change also includes a fix to parameterize the hbase artifact,
since the structure of the dependencies have changed along the 0.9x
line. It also cleans some unneeded dependencies in a few poms.
Re-enable maven-install-plugin for a few projects.

Without this, running specific targets directly (e.g.
mvn -f assembly/pom.xml) doesn't work.
Propagate classpath to child processes during testing.

When spawning child processes that use the Spark assembly jar in
unit tests, all classes needed to run Spark are needed. If the
assembly is built using the "*-provided" profiles, some classes
will not be part of the assembly, although they'll be part of the
unit test's class path since maven/sbt will make the dependencies
available.

So this change extends the unit test's class path to the child
processes so that all classes are available.

I also parameterized the "spark.test.home" setting so that you
can do things like "mvn -f core/pom.xml test" and have it work
(as long as you set it to a proper value; unfortunately maven
makes this super painful to do automatically, because of things
like MNG-5522).
Introduce "SPARK_DIST_CLASSPATH".

This env variable is processed by compute-classpath.sh and appended
to the generated classpath; it allows distributions that ship with
reduced assemblies (e.g. those built with the "hadoop-provided"
profile) to set it to add any needed libraries to the classpath
when running Spark.
Propagate SPARK_DIST_CLASSPATH on Yarn.

Yarn builds the classpath based on the Hadoop configuration, which may
miss thing in case non-Hadoop classes are needed (for example, when
Spark is built with "-Phive-provided" and the user is running code
that uses HiveContext).

So propagate the distribution's classpath variable so that
the extra classpath is automatically added to all containers.
Redirect child stderr to parent's log.

Instead of writing to System.err directly. That way the console
is not polluted when running child processes.

Also remove an unused env variable that caused a warning when
running Spark jobs in child processes.
Remove duplicate hive profile.
Add snappy to hadoop-provided list.

It's a dependency of avro.
Update dependencies for hive-thriftserver.
Fix HiveThriftServer2Suite with *-provided profiles.
Remove unused profile.
Restore jetty dependency.

Streaming only needs the servlet API, but jetty pulls in its own
repackaged servlet api jar for whatever reason, so instead of adding
more jetty cruft to the build, just use the coarse dependency.
Restore flume-provided profile.

It's actually useful for the examples jar.
Fix CliSuite with provided profiles.