The typo3/testing-framework provides two TYPO3 extensions,
which are required and bound to every created functional
test instance.

Adding missing `composer.json` for these two extensions.

Releases: main, 8

The `typo3/testing-framework` creates functional test instances
as "classic" mode instances, writing a `PackageStates.php` file
composed using composer information, provided and handled by the
internal `ComposerPackageManager` class. Extensions in the state
file are not sorted based on their dependencies and suggestions.

To mitigate this and having a correctly sorted extension state
file, the `PackageCollection` service has been introduced with
the goal to resort the extension state file after the initial
write to provide the correct sorted extension state.

The extension sorting within the state file is important, as the
TYPO3 Core uses this sorting to loop over extensions to collect
information from the extensions, for example TCA, TCAOverrides,
ext_localconf.php and other things. Package sorting is here very
important to allow extensions to reconfigure or change the stuff
from other extensions, which is guaranteed in normal "composer"
and "classic" mode instances.

For "classic" mode instances, only the `ext_emconf.php` file is
taken into account and "composer.json" as the source of thruth
for "composer" mode instances since TYPO3 v12, which made the
`ext_emconf.php` file obsolete for extensions only installed
with composer.

Many agencies removed the optional `ext_emconf.php` file for
project local path extensions like a sitepackage to remove
the maintenance burden, which is a valid case.

Sadly, the `PackageCollection` adopted from the TYPO3 Core
`PackageManager` did not reflected this case and failed for
extensions to properly sort only on extension dependencies
and keys due the mix of extension key and composer package
name handling. Extension depending on another extension
failed to be sorted correctly with following exception:

    UnexpectedValueException: The package "extension_key"
    depends on "composer/package-key" which is not present
    in the system.

This change modifies the `PackageCollection` implementation
to take only TYPO3 extension and system extension into account
for dependency resolving and sorting, using `ext_emconf.php`
depends/suggest information as first source and falling back
to `composer` require and suggestion information.

Resolves: #541
Releases: main, 8

…Manager`

The `ComposerPackageManager` has been introduced to streamline
the functional test instance creation process and provide all
selected extensions (system, custom and test fixture) within
the test instance, which original simply used relative path
names for classic mode instances or a simple extension key:

For `$coreExtensionsToLoad`:

* typo3/sysext/backend
* backend

For `$testExtensionsToLoad`:

* typo3conf/ext/my_ext_key
* my_ext_key

With `typo3/cms-composer-installers` version 4.0RC1 and
5 these paths could not be found anymore, because TYPO3
system extensions and extensions are no longer installed
into the classic paths in a composer mode instance and
left in the vendor folder, which is the case for usual
root project or extension instance.

Using the available composer information to determine the
source for extensions unrelated to the real installation
path, which can be configured with composer, was the way
to mitigate this issue and `ComposerPackageManger` has
been implemented to process these lookups while still
supporting test fixture extensions not loaded by the root
composer.json directly.

The implementation tried to provide backwards compatible
as much as possible along with fallback to use folder names
as extension keys by simply using `basename()` in some code
places and including not obvious side effects and lookup
issues. `basename()` was also used on valid composer package
names to resolve composer package name for that value as
extension key for loaded packages, which leads to fetch the
wrong composer package.

The standlone fluid `typo3fluid/fluid` composer package name
resolved and retrieved the TYPO3 system extension package
`typo3/cms-fluid` using `getPackageInfo()`, which lead to
issues in other places, for example the dependency ordering
and resolving class `PackageCollection`.

This change streamlines the `ComposerPackageManager` class
to mitigate building and using invalid values to lookup
extension composer package names and harden the registration
process of extension even further.

Guarding unit tests are added to cover this bugfix.

Resolves: #553
Releases: main, 8

Using the `typo3DatabasePort` environment variable to
define the database server port string-casts the value
to an string which is not compatible with the mysqli
method `mysqli::real_connect()` and fails with:

  TypeError: mysqli::real_connect(): Argument #5 ($port)
  must be of type ?int, string given

This change casts the database port to an integer in case
a port is provided to avoid PHP TypeError when passing to
`mysqli::real_connect()` to align with `ConnectionPool`,
which is not used to create the database for the functional
test instance.

Resolves: #631
Releases: main, 8

This change removes the enabling of feature `redirects.hitCount`
within codeception acceptance test setups to stay on TYPO3 Core
defaults.

That has been preared with temporary solution for TYPO3 Core tests [1].

* [1] https://review.typo3.org/c/Packages/TYPO3.CMS/+/87280

Resolves: #554
Releases: main