SparkFetcher should delay collecting uncompleted Spark apps

Nobody has claimed this yet.

I've been debugging Dr. Elephant on Spark 2.1 and noticed that some of the apps are never aggregated. Roughly it goes as follows:

1. `AnalyticJobGeneratorHadoop2` queries the RM for a list of finished jobs/apps.
2. `SparkFetcher` gets all the new Spark apps. Some of them are truly finished, others (for reasons I don't yet completely understand) have `completed: false` in a list of attempts.
3. The fetcher tries to resolve them and gets a 500 Internal Server Error during `getLogData` (see #225). The app gets added to the retry queue and, if we're really unlucky, gets dropped after three attempts.

The trace on the History Server side is

```
17/03/23 22:45:31 INFO history.ApplicationCache: Failed to load application attempt application_1490183156364_349617/Some(1)
17/03/23 22:45:31 WARN servlet.ServletHandler:
javax.servlet.ServletException: org.glassfish.jersey.server.ContainerException: java.io.FileNotFoundException: File does not exist: /var/log/spark2/application_1490183156364_349617_1.lz4.inprogress
at org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:66)
...
```

which suggests this could be the case for the WebHDFS-based `SparkLogClient` as well (although the HTTP code would probably be 404).

The problem, as far as I understand it, is that only the apps with `completed:true` have logs and `SparkFetcher` ignores that fact. A proper fix for this would be to delay the analysis on the app until it has completed, which could be done by not incrementing the counter in `AnalyticJob.retry`.

I am curious whether somebody had similar issues with Spark 2.1 or earlier versions? The `completed:true` contract is undocumented and could be plain wrong, do you think we should implement it in `SparkFetcher` anyway?

Start with SparkFetcher and AnalyticJob.retry, then inspect SparkLogClient and the flow that handles applications with completed:false. Reproduce or trace the retry path for an uncompleted Spark app and determine how analysis should be deferred without dropping the app after three attempts; verify behavior for completed and incomplete attempts.

Written by the indexing model from the issue text.