[5.x] Fixes #1616

[amirhshokri]

Fixes #1616

[gerardnll]

This does not fix the problem of using a 'horizon' connection. I don't get the point of this PR and the one that introduced this check.

Horizon config by default uses the redis connection 'default'. Why can't we add a 'horizon' connection and use that one instead of the 'default' one so we can use another redis database to store horizon data? The code adds/overrides the 'prefix' option but uses the other settings as it would do with the 'default' connection. I may not want the horizon data on the redis db 0 mixed with other things... that's why i created the 'horizon' connection.

@taylorotwell

[amirhshokri]

In fact, this is a validation that was created according to the documentation, and it’s better not to use a connection with horizon name. You can create a connection named horizon_data and use that instead.

However, the main issue is related to cached previous configurations that conflict with the current validation.
For this reason, I proposed #1618, but it was not accepted.

@gerardnll

[gerardnll]

Documentation states that 'it should not' be used. But it's not mandatory to use another connection other than 'horizon'. You can provide any connection in 'use' and the code will overwrite any fields it needs. That's why there's a warning, so you know some database parameters could be overriden, in this case, only 'prefix' is changed.

I think the original #1615 should be reverted, and allow it as it's been until now, because it's a breaking change as it's not mandatory to use another connection name.

[punyflash]

This breaks artisan optimize. Revert

[Gummibeer]

So this whole thing started because of this part in the docs? 🤯

Horizon uses a Redis connection named horizon internally. This Redis connection name is reserved and should not be assigned to another Redis connection in the database.php configuration file or as the value of the use option in the horizon.php configuration file.
— https://laravel.com/docs/12.x/horizon#configuration

Things are in the docs as they aren't in code. And Laravel was never restrictive about any assumptions. You are just f*ed and on your own when you play different. I don't get why this was put in in the first place and even less why it's not simply and fully reverted? Let me do what I want. When checking the issues I couldn't find a single one that hit this problem @amirhshokri tried to fix with that!? So why do we try to solve an issue that doesn't exist and even when it would exist, it's clearly documented.
PR #1615 has errored the Horizon installations of hundreds/thousands of devs who had to pin the version now without any benefits added by this restriction. I could understand it when this would bring several issues per week in here - but it doesn't. So it's an overengineered and underthought optimization for the sake of optimization.