[10.x] Adds Tappable and Conditionable to Relation class

[DarkGhostHunter]

Fixes #50123

Since the Relation class forwards calls to the underlying Query instance, using tap, when and unless methods do not inherit the Relation methods.

For example, calling wherePivot('is_cool', true) after these methods will make the query set WHERE "table"."pivot" = 'cool" instead of using the wherePivot() method of the relation. This produces the Query instance to use its helpers disregarding anything else.

$tag->posts()->when(true)->wherePivot('is_cool', true)->get();

// Before
SELECT * FROM "posts" INNER JOIN "post_tag" ... WHERE "post_tag"."pivot" = 'is_cool'

// After
SELECT * FROM "posts" INNER JOIN "post_tag" ... WHERE "post_tag"."is_cool" = 1

By adding these traits directly into the Relation class itself, it fixes that problem.

Breaking changes?

None that is documented and could collision with this change.

The only edge case I can think of is someone receiving the Builder instance inside these methods callbacks, but that was deprecated in favor of the BuilderContract, so its a far stretch.

use Illuminate\Database\Eloquent\Builder;
// use Illuminate\Contracts\Database\Eloquent\Builder; <-- Should be using this instead.

$tag->post()->when(true, function (Builder $query) {
    // ...
});

[taylorotwell]

Reverted due to multiple breaking changes.

[RTippin]

@taylorotwell Was just commenting to alert you all. My packages had their tests fail last night due to this change, as I rely on use Illuminate\Database\Eloquent\Builder; and was not aware of any deprecations in that regard or to use the interface as stated above, so long as we are still in 10.x

[DarkGhostHunter]

Since all test passed, I thought it was OK. My mistake, but couldn't foresee the breaks. Except on the Builder contract, of course (which should be used when dealing with relation queries).