Establish ECA 2.0 compatibility

The error originates from the linked issue. In that issue I linked to a discussion where I described why that change is a problem.

Overall, the main problem here is that ECA 1.1 -> 1.2 contains breaking API changes. And since breaking API happens between two minor releases of a stable release, I see this as a bug within ECA, not this integration module. No matter the perspective on this - it means additional effort in taking care of such changes, and no one is paying me to fix them. If that change would've happened on a major release update (like 1.x to 2.x) then I'd be willing to take care about it, also in my free time.

Now we have the problem, that this does not only mean additional effort by trying to "fix" this in code, but also it kinda forces all integration modules like this one to follow the "version pattern" of ECA, or at least somehow dealing with it. Also for this topic: no matter the perspective - it also means means additional effort.

ohhhh the changes between eca 1.1 and 1.2 are the cause? when the discussion was about those changes i've assessed it only from a eca point of view and there making php 8.1 the minimum requirement made sense. but i havent fully grasped the implications for modules having eca as a dependency. the issue illustrates the problem well then. would it make sense instead of going 1.1 to 1.2 go directly to 2.0 with eca instead?

would it make sense instead of going from 1.1 to 1.2 with eca instead go to 2.0 directly?

When ECA wants to follow core's version semantics, then yes. I've already discussed this with the maintainer as can be seen in the linked discussion of the related issue.

Started an MR for a new release, since ECA 2.0.x is now available and can be declared as a dependency. Should that become a 2.0.x release here too?

This makes sense to be addressed once ECA v2 reaches beta, as beta releases are usually not supposed to make major API changes anymore.

May I ask what's the concrete benefit of changing the API from this
public function getData(string $key) { to this public function getData(string $key): mixed { ?

The DataProviderInterface will maybe change anyway once there will be a definition layer introduced for provided tokens. But for now, I'm struggling to justify a specific release branch only because of the highlighted API change above (unless there's a viable reason for it).

Might be worth first clarifying 📌 Consider dropping maintenance support for this module Active before putting any more effort into this issue.