Release 2020.04

[joakim-hove]

This issue is created to serve as a focal point for discussion/information about the 2020.04 release. My plan is to keep general information in the issue description, and then we can possibly create separate comments in in this issue for specific topics.

GitHub milestone and label
I have created a milestone "Release 2020.04" in all the GitHub repositories. You are encouraged to mark your PR's with this milestone, at least when the dates for creation of release branches draws near it is important that the PR's are marked. The way I interpret these milestones markers is as follows:

1. Before the release branches are created this is just a heads up to
   me that: "Joe developer want's this feature in the release".
2. After the release branches are created I will watch the PR; if it is
   merged before the final release there are two possibilities:
   1. I decide to backport the feature to the release branch - in that
      case the "Backported 2020.04" label is added to the PR.
   2. I decide to not backport the feature to the release branch - in
      that case the PR will be removed from the "Release 2020.04"
      milestone.

Important dates

1. Creation of release branches: Wednesday 22.th of April
2. Creation of release candidate 1. Friday 24.th of April
3. Release canditate2 / final Friday 1.st of May
4. (Absolute final release date: Friday 8.th of May)

[joakim-hove]

Restart without historical schedule section?

Eclipse does not consider the historical part of the Schedule section when restarting, all necessary well and group information is collected from the restart file, and the interpretation of the SCHEDULE keywords starts right at the restart date. For opm/flow the restart semantics has traditionally been different:

1. The Schedule file is parsed in it's entirety - and that information is used to initialize wells and groups and such.

2. Only the solution fields like PRESSURE and SWAT is fetched from the restart file.

With the ongoing (very close to "complete") work: #1396 flow is also capable of restarting without access to the restart file - for flow this is regulated with a command line switch. To restart based on the full schedule file (original opm behaviour):

flow --sched-restart=true  CASE.DATA

and the new capability of restarting based only on the restart file is invoked with:

flow --sched-restart=false CASE.DATA

Currently the --sched-restart=true is the default behavior; we should be going in a direction where this is changed to --sched-restart=false is the default behavior - but my question is whether we should change the default for the release or not? To evaluate this question it is important to keep in mind that the new --sched-restart=false is complex, and only tested on a limited set of models - I therefor consider it quite probable that models which have worked with the original opm restart scheme (i.e. --sched-restart=true) will fail to restart with the new --sched-restart=false.

My preference is:

1. For the release we retain the --sched-restart=true behavior.
2. Soon after the release we switch the default to --sched-restart=false - hopefully this will weed out enough problems among developers that it is a safe setting for the next release.