When relying on static config instead of an explicitly set minLength then this message would show without the value, like "it must be or more characters long".
Use-case: if a module is defining its own authenticator and you want to disable it, as it seems we don't have `unregister_authenticator()` anymore and I can't spot how to remove YAML-based injected properties, then this lets you mark it as null or false to prevent it from erroring out when it attempts to call `supportedServices()`
Two functions interact with the LoginAttempt object which when used in conjunction with BasicAuth result in significant performance degradation over time, as the LoginAttempts Table fills.
This fix adds an index to the lookup column EmailHashed and removes the Email filter part of getByEmail() so it can use the index resulting in a much faster query.
For more information see https://github.com/silverstripe/silverstripe-framework/issues/8389
Fixes regression from 3.x, where sessions where lazy started as required:
Either because an existing session identifier was sent through with the request,
or because new session data needed to be persisted as part of the request execution.
Without this lazy starting, *every* request will get a session,
which makes all those responses uncacheable by HTTP layers.
Note that 4.x also changed the $data vs. $changedData payloads:
In 3.x, they both contained key/value pairs.
In 4.x, $data contains key/value, while $changedData contains key/boolean to declare isChanged.
While this reduces duplication in the class, it also surfaced a bug which was latent in 3.x:
When an existing session is lazily resumed via start(), $data is set back to an empty array.
In 3.x, any changed data before this point was *also* retained in $changedData,
ensuring it gets merged into existing $_SESSION data.
In 4.x, this clears out data - hence the need for a more complex merge logic.
Since isset($this->data) is no longer an accurate indicator of a started session,
we introduce a separate $this->started flag.
Note that I've chosen not to make lazy an opt-in (e.g. via start($request, $lazy=false)).
We already have a distinction between lazy starting via init(), and force starting via start().
