Fix multilingual install on Drupal dev version for CLI utilities

This patch changes the filename of the downloaded file to drupal-8.6.x.fr.po for both non-interactive and interactive installs. NodeTypeTranslationTest fails now the same way it does for stable releases because non-interactive multi-lingual install works! yay :)

However I think it would be better if the filename did not change.

Here's a fix for NodeTypeTranslationTest that ensures we don't download from localize.drupal.org

Found a better fix. The problem is occurring because _install_prepare_import() via a browser doesn't have information static cached in locale_translation_get_projects(). Clearing that cache makes CLI and browser install work the same way.

The proof patch is just the fix - which will have NodeTypeTranslationTest broken...

Looking at this a little bit more we can do a better fix since the problem occurs when the project cache get populated during the delete of the english language which happens as part of install_download_additional_translations_operations().

Okay I finally now understand the problem I think we have two ways to solve it!

1. Clear static cache in _install_prepare_import()

In this method we manipulate the project information so that we use the downloaded translation files. However when installing via CLI the project information is already cached and does not match what we are using here.

2. Make install_check_translations() use the same filename it would do if the language installed later

The problem is occurring because in this early install method we create a file like 8.6.0-dev whereas in locale_translation_build_projects() we change 8.6.0-dev to 8.6.x. We override this information in _install_prepare_import() which makes it work interactively but not in CLI because of the static cache.

I think doing both option 1 and option 2 together is the best way to solve this because it results in the same filename that you'd have if you add the language after installation and the information being set in _install_prepare_import() being used for both CLI and browser install. Therefore merging the fix in #5 in and improving docs. And moving the clear cache to _install_prepare_import().

I have tested this both with drush using the --locale option and the interactive installer. Both result is a site installed in a language other than english being translated. Unfortunately we want tests to not depend on localise.drupal.org so an automated test is not possible. However given that the changes are to a downloaded filename and clearing a static cache I think they are pretty minimal.

Making stable and dev versions behave the same is a major bug as is have the test suite pass when the version is stable - see #2796757-8: Failing test with stable version string. As that issue is now postponed on this one marking this issue major.

@dawehner test coverage is a bit tricky because we explicit don't want to go l.d.o and we already have test coverage of pre-placing translation files. The bug happens because of different ways of interpreting the fallback solution in place on l.d.o. Basically I'm not sure that the current design of locale in the installer and the installer itself makes this testable.

I worked out how to test this. It's pretty simple really. We can set up the translation files with different strings at the beginning of a new interactive install and have a translation so we can see if it worked or not.

The test only patch is the interdiff.

Re #17.1 Nope :) fixed.

@plach pointed out that the regex would match 8.0.0x and 0x would be patch version.

The current _install_get_version_info() actually does nothing to change the validity of the version string but it feels worth it to have a correct regex.

+++ b/core/modules/locale/tests/src/Functional/LocaleNonInteractiveDevInstallTest.php
@@ -0,0 +1,21 @@
+    return $version['major'] . '.' . $version['minor'] . '.x';

+++ b/core/modules/locale/tests/src/Functional/LocaleNonInteractiveInstallTest.php
@@ -0,0 +1,57 @@
+    return $version['major'] . '.0.0';

This gives us coverage of both types of patch - ie. 'x' or '0'

Leaving at rtbc as this is a very minor change that I've tested on regex101.com and with out test coverage. Also note that the only runtime usage is:

preg_match('/drupal-([0-9a-z\.-]+)\.' . $langcode . '\.po/', $filename, $matches);

in _install_prepare_import() where we are working with files downloaded from localize.drupal.org so the version numbers come from there and therefore I guess _install_get_version_info() has been written in way that assumes l.d.o produces valid file names.

Crediting @plach and @dawehner for reviews.