In Corda 4, FinalityFlow was updated to become an initiated flow, in order to ensure a node does not have to accept any signed transaction it receives without being able to check it first. The old behaviour of FinalityFlow was gated behind a targetPlatformVersion check, to prevent apps targeting V4 from using the old behaviour.
This is problematic for a few reasons. For an app wishing to be backwards compatible with a version running on V3, this forces the app to set targetPlatformVersion = 3, even if the app is thoroughly tested against V4. This goes against the purpose of the targetPlatformVersion. Another consequence is that an app remains pinned to targetPlatformVersion = 3 until it is sure that there are no other apps running at a lower version in the network, which would prevent newer versions of the app from taking advantage of features gated behind targetPlatformVersion checks. (Note that the restriction only prevents a new version of the app from initiating FinalityFlow with the old version - the old version is able to initiate a FinalityFlow and the new version will handle it, assuming the app has been written correctly.)
This fix removes the targetPlatformVersion check from FinalityFlow, and also provides a few documentation updates to clarify what level of testing would be expected to set a targetPlatformVersion.
With (Contract JARs) rolling upgrades the downgrade rule cannot be effectively check as the platform can't tell the difference between a transaction that's downgrading because of an attack, vs a transaction that's downgrading because Alice has upgraded but Bob hasn't yet. During a rolling upgrade we would expect state versions to fluctuate up and down as data gets read/written by a mix of nodes. With the feature as implemented Alice will upgrade and start trading with Bob. Bob will be able to read and process the states Alice sent him, but the moment he tries to consume such a state he will fail. This will result in cascading flow deaths and a hung business network the moment an upgrade starts.
This removes the need for the shareParentSessions parameter of FlowLogic.subFlow. It also has the flow's version number so FlowVersion is now no longer needed.
Core flows, which are baked into the platform, are also versioned using the platform version of the node. Several core flows, such as the data vending ones, which were provided via plugins are now instead baked into the node.
