Logic for determining which security releases should be considered if site has a dev release is installed is untested

Problem/Motivation

working on #3100110: Convert update_calculate_project_update_status() into a class

I realized this logic in update_calculate_project_update_status() is untested:

// If we're running a dev snapshot and have a timestamp, stop
// searching for security updates once we hit an official release
// older than what we've got. Allow 100 seconds of leeway to handle
// differences between the datestamp in the .info.yml file and the
// timestamp of the tarball itself (which are usually off by 1 or 2
// seconds) so that we don't flag that as a new release.
if ($project_data['install_type'] == 'dev') {
if (empty($project_data['datestamp'])) {
// We don't have current timestamp info, so we can't know.
continue;
}
elseif ($release->getDate() && $project_data['datestamp'] + 100 > $release->getDate()) {
// We're newer than this, so we can skip it.
continue;
}
}

If we alway continue if $project_data['install_type'] == 'dev' the test will still pass

Proposed resolution

First we should determine 'datestamp' is actually still a valid field . I don't see this https://updates.drupal.org/release-history/drupal/current
I also don't see where we are setting but maybe it is there somewhere.

We should debug update_calculate_project_update_status() using real XML from drupal.org and see if $project_data['datestamp'] is ever actual set. If not we may want to remove this logic.

if it is set we need a test:
Have a site that is running a dev release.

1. for a project that has no datestamp then not security releases should be shown(according to current logic)
2. For a project where project datestamp is less than the date on a security release then the security release should be shown
3. For a project where project datestamp is greater than the date on a security release then the security release should NOT be shown

For case 1) we need a new XML because all our current XML would have datestamp. We should ask @drumm if there should ever be project xml with a datestamp field. We might want to make a follow-up to remove this logic.

For case 2) and 3) we could add 1 new XML that has 2 security release one with date that is before the project datestamp and 1 after. 1 of the releases should be shown the other should not.

Remaining tasks