…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       | MITThis new iteration (following up#57462,#56985 andsymfony/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#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, seehttps://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-------98156f7 Introducing container non-empty parameters

…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       | MITThis new iteration (following upsymfony/symfony#57462,symfony/symfony#56985 andsymfony/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 onsymfony/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, seehttps://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