This closes #1663

This closes #1653

This closes #1650

They are not specific to RocksDB, just utilities for copying local
folders to/from HDFS. Moving them to flink-streaming-java means that
they are always in the classpath of the TaskManager, not only in the
user-code jar when using RocksDB. If they are only in the user-code jar
the external process runner cannot find the class files, leading to
ClassNotFoundExceptions.

This closes #1655

[FLINK-3413] [streaming] Make implicit conversions from Java DataStream to Scala DataStream explicit

This also clean up a lot of JavaDocs in various Scala DataStream API classes.

This closes #1642.

[FLINK-3401] [streaming] [api breaking] AscendingTimestampExtractor only logs violations of ascending timestamp order.

The user can also explicitly set an 'IgnoringHandler' or a 'FailingHandler', which do nothing on violations,
respectively fail hard.

 - one class handled periodic watermarks
 - the other class handled watermarks triggered by elements

This also makes sure that any timestamp assigner / watermark generators cannot generate
negative watermarks

This closes #1646

This adds dedicated WindowAssigners for processing time and event time.
timeWindow() and timeWindowAll() respect the TimeCharacteristic set
on the StreamExecutionEnvironment.

This will make the easy stuff easy, i.e. using time windows and quickly
switching the time characteristic. Users will then have the flexibility
to mix different kinds of window assigners in their job.

This also expands the translation tests to verify that the correct
window operators are instantiated.

[FLINK-3420] [api-breaking] Remove utility functions 'readTextFileWithValue' and 'readFileOfPrimitives' from StreamExecutionEnvironment

These methods are highly specific for very niche cases of bounded data stream processing.
As such, the disadvantages (bloat and lock the API, lock the development into support) outweigh the benefit.

This closes #1648

Because the implicit conversion creates a new ExecutionEnvironment, it leads to
strange errors when used withing programs with more than one source.

This closes #1563

This closes #1524

This closes #1635

Update index.js and reset vendor.css and vendor.js to master version

Update web-dashboard

Remove duplicate flink-runtime-web dependency from flink-tests

Remove not used ProgramStopException

Change stopping behaviour to only work in job status RUNNING

This closes #750.

- added JobType to JobGraph and ExecutionGraph
- added interface Stoppable, applied to SourceStreamTask
- added STOP signal logic to JobManager, TaskManager, ExecutionGraph
- extended Client to support stop
- extended Cli frontend, JobManager frontend
- updated documenation

Fix JobManagerTest.testStopSignal and testStopSignalFail

The StoppableInvokable could not be instantiated by Task because it was declared as a private
class. Adds additional checks to verify that the stop signal behaves correctly.

Auto-detect if job is stoppable

A job is stoppable iff all sources are stoppable

- Replace JobType by stoppable flag
- Add StoppableFunction and StoppableInvokable to support the optional stop operation
- added REST get/delete test (no extra YARN test -- think not required as get/delete is both tested)
- bug fix: job got canceld instead of stopped in web interface
- Add StoppingException
- Allow to stop jobs when they are not in state RUNNING

Second round of Till's comments

A RestartStrategy defines how the ExecutionGraph reacts in case of a restart. Different strategies
are conceivable. For example, no restart, fixed delay restart, exponential backoff restart, scaling
in/out restart, etc.

Expose RestartStrategy to user API

This removes the setNumberExecutionRetries and the setDelayBetweenRetries on the ExecutionEnvironment and
the ExecutionConfig. Instead the more general RestartStrategy can be set. In order to maintain the
separation between the runtime and api module, one sets a RestartStrategyConfiguration which is transformed
into a RestartStrategy on the JobManager.

Replace old execution-retries configuration parameters by restart-strategy.

Add FixedDelayRestartStrategy test case

Reintroduce old configuration values and API calls for the deprecated restart mechanism

The old configuration values and API calls will be respected if no explicit
RestartStrategy has been set. The values, if correct, are used to instantiate
a FixedDelayRestartStrategy.

Add deprecation comments to the JavaDocs

Add logging statement for job recovery

Fix JobManagerProcessFailureBatchRecoveryITCase by introducing a job recovery timeout

Add proper annotations to RestartStrategies

Let ExecutionGraphRestartTest extend TestLogger

This closes #1470.

Closes #1638