…th libpcre2-10.43

The error handling function in the StaticPrefixCollection class has been extended. A new check for 'Compilation failed: length of lookbehind assertion is not limited' message error was added to improve the error capture process.

… for compatibility with libpcre2-10.43 (Lustmored)

This PR was merged into the 5.4 branch.

Discussion
----------

[Routing] Enhance error handling in StaticPrefixCollection for compatibility with libpcre2-10.43

The error handling function in the StaticPrefixCollection class has been extended. A new check for 'Compilation failed: length of lookbehind assertion is not limited' message error was added to improve the error capture process.

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | Fix #54067
| License       | MIT

Recent changes in libpcre2 have changed the error message we are trying to catch in StaticPrefixCollection. The change comes from this commit (please take a look at changes in `src/pcre2_error.c`):

PCRE2Project/pcre2@1e78b77

This PR checks for both possible error messages for backwards-compatible way of handling errors.

I did not add any tests as current tests are throwing PHP warnings when run with newer libpcre2, which are gone after the proposed change and I'm unsure how to proceed with that fact.

Commits
-------

7183330 Enhance error handling in StaticPrefixCollection for compatibility with libpcre2-10.43

…data properties (derrabus)

This PR was merged into the 5.4 branch.

Discussion
----------

[DoctrineBridge] Safeguard dynamic access to Doctrine metadata properties

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Issues        | Fix #54077
| License       | MIT

Commits
-------

9eadc22 Safeguard dynamic access to Doctrine metadata properties

This PR was merged into the 5.4 branch.

Discussion
----------

[HttpClient] Fix deprecation on PHP 8.3

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

Commits
-------

9407a1b [HttpClient] Fix deprecation on PHP 8.3

…scenarios

…ect end-user scenarios (llupa)

This PR was squashed before being merged into the 5.4 branch.

Discussion
----------

[Security][Tests] Update functional tests to better reflect end-user scenarios

| Q             | A
| ------------- | ---
| Branch?       | 5.4
| Bug fix?      | no
| New feature?  | no
| Deprecations? | no
| Issues        | N/A
| License       | MIT

Pinging `@wouterj`

This PR is related to #53851 's Context.

> A person going through Symfony docs for the first time wanted to create their own LoginFormType as a next step in their learning Symfony journey and noticed that you can submit empty username/password with form login.
>
> They wanted to disallow this and tried to add validation. To validate a login form is not so straight forward as it either needs to be done with a custom authenticator (complex validation) or user provider if the data checks are simple.

Following comments:

#53851 (comment)
> Given the broken high-deps build, I wonder if this shouldn't even be done with a deprecation notice before making it throw in 8.0?

#53851 (comment)
> These are 3 tests submitting an empty login form to trigger a CSRF token error. This new condition now takes precedence, meaning it returns the wrong error.
I don't think that is something we have to worry about (in both situations, login errors), it rather reveals a bad test in our codebase. I can't think of a use-case that would result in success and will become a failure after this merge.

#53851 (comment)
> I think we need consensus on whether we find this a hard BC break that deserves a smooth upgrade path, but the test need to be fixed whatever the conclusion

Commits
-------

4155f66 [Security][Tests] Update functional tests to better reflect end-user scenarios

released v5.4.37