feature #57611 [DependencyInjection][FrameworkBundle] Introducing con…

…tainer non-empty parameters (yceruto)

This PR was merged into the 7.2 branch.

Discussion
----------

[DependencyInjection][FrameworkBundle] Introducing container non-empty parameters

| Q             | A
| ------------- | ---
| Branch?       | 7.2
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Issues        | -
| License       | MIT

This new iteration (following up symfony/symfony#57462, symfony/symfony#56985 and symfony/recipes#1317) is about to improve the DX when we're dealing with optional parameters (this is the case for `kernel.secret` now and likely others out there) .

Nicolas regarding your comment on symfony/symfony#57462 (comment), I tried, but after some tests I realized that the impact of deprecating the `kernel.secret` is huge and, in some cases, counterproductive, as we used to reference that parameter in many configurations, see https://github.com/search?q=language%3APHP+%25kernel.secret%25+&type=code&p=3, which is currently a convenient way to share a config value.

So I gave this new concept for container parameters a try. Basically, a non-empty parameter is one that must exist and cannot be [empty](https://www.php.net/manual/en/function.empty.php). It's evaluated when the `ParameterBag::get()` method is invoked.

Additionally, we can now connect the parameter with its source by passing a custom error message with details on how to proceed if it fails, thus improving the DX.

This is what we can achieve with this feature:
```php
$container = new ContainerBuilder();

if (isset($config['secret'])) {
    $container->setParameter('app.secret', $config['secret']);
}

// NEW
$container->nonEmptyParameter('app.secret', 'Did you forget to configure the "app.secret" option?');

$container->register('security_service', 'SecurityService')
    ->setArguments([new Parameter('app.secret')])
    ->setPublic(true)
;
```
when the `security_service` is initiated/used, the `app.secret` parameter will be evaluated based on the non-empty conditions. If it's missing or empty, a helpful exception message will be thrown.

Before (case when it's missing):
```
You have requested a non-existent parameter "app.secret".
```
After:
```
You have requested a non-existent parameter "app.secret". Did you forget to configure the "app.secret" option?
```

This would also address our concern about third-party services depending on the `kernel.secret` parameter when `APP_SECRET` is empty (and the `secrets` option is disabled). In that case, even if they are not checking for empty secret value in their own, it'll fail.

Commits
-------

98156f7d64 Introducing container non-empty parameters

DependencyInjection/FrameworkExtension.php

@@ -309,6 +309,7 @@ public function load(array $configs, ContainerBuilder $container): void
         if (isset($config['secret'])) {
             $container->setParameter('kernel.secret', $config['secret']);
         }
+        $container->nonEmptyParameter('kernel.secret', 'A non-empty value for the parameter "kernel.secret" is required. Did you forget to configure the "framework.secret" option?');
 
         $container->setParameter('kernel.http_method_override', $config['http_method_override']);
         $container->setParameter('kernel.trust_x_sendfile_type_header', $config['trust_x_sendfile_type_header']);

composer.json

@@ -21,7 +21,7 @@
         "ext-xml": "*",
         "symfony/cache": "^6.4|^7.0",
         "symfony/config": "^6.4|^7.0",
-        "symfony/dependency-injection": "^7.1.5",
+        "symfony/dependency-injection": "^7.2",
         "symfony/deprecation-contracts": "^2.5|^3",
         "symfony/error-handler": "^6.4|^7.0",
         "symfony/event-dispatcher": "^6.4|^7.0",