.htaccess ExpiresDefault (2W) is much too low. Should be ~1Y

I decided to use
ExpiresDefault "access plus 1 year" notation, as it's easier to read than the seconds syntax used before, but of course we can also use that.

I think this is a lot more self-explaining.

Thanks @cilefen you're right! Feature request is better here.

Here's the patch to review, so we don't have to rebase this all the time ;)

#3159964: Improve example for https redirect in .htaccess fixed the same in the dropsolid_rocketship profile, so we're getting closer to RTBC as this was tested on many sites before.

Needs a reroll, the .htaccess has been changed in the meantime, as it seems.

Thanks @Grevil. Having a closer look at the failing tests, 7 of them seem unrelated to me, but this one has to be fixed:

1	Composer.Composer
	1	Composer.Drupal\Tests\ComposerIntegrationTest
	✗	
Drupal\Tests\ComposerIntegrationTest

fail: [Other] Line 0 of sites/default/files/simpletest/phpunit-117.xml:
PHPUnit Test failed to complete; Error: PHPUnit 9.5.24 �[44;37m#StandWith�[0m�[43;30mUkraine�[0m

Testing Drupal\Tests\ComposerIntegrationTest
........S.................................F.................      60 / 60 (100%)

Time: 00:00.102, Memory: 6.00 MB

There was 1 failure:

1) Drupal\Tests\ComposerIntegrationTest::testExpectedScaffoldFiles with data set #6 ('.htaccess', 'assets/scaffold/files/htaccess')
Scaffold source and destination files must have the same contents.
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
   # Enable expirations.\n
   ExpiresActive On\n
 \n
-  # Cache all files for 2 weeks after access (A).\n
-  ExpiresDefault A1209600\n
+  # Cache all files for 1 year after access.\n
+  ExpiresDefault "access plus 1 year"\n
 \n
   \n
     # Do not allow PHP scripts to be cached unless they explicitly send cache\n

/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:96
/var/www/html/core/tests/Drupal/Tests/ComposerIntegrationTest.php:203
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:726
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestSuite.php:672
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestSuite.php:672
/var/www/html/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:673
/var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php:143
/var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php:96

FAILURES!
Tests: 60, Assertions: 398, Failures: 1, Skipped: 1.

Here we go! :)

Much traffic at 10.1.x-dev while I think the patch / MR itself is fine now. Should we better target 10.0.x for review?

Rerolled, thx. As this is a "tiny" (LOC) change, we should perhaps try to decide what to do here for not having to rebase this easy day? :)

Thanks @_nod! Looking at #3054821: Include Cache-Control header on 301 redirects. and thinking about explicit rules per mime type I think we should keep this as-is and let the redirect do its own thing in the other issue.

Otherwise, this will end up for us in having to update the mime types for every new image type etc. - I don't thing that's a good thing.
For such an example see https://www.supertechcrew.com/htaccess-rules-security-cache-redirect/ > "Caching rules"

Do you agree?

Setting this back to "Needs review" for that reason. I still think the changes are good.

Funny question, I know. But should we backport this to Drupal 7? Also 14d there...