[11.x] Add in() and inHidden() functions to Context Stacks

[lessevv]

I'm really liking the addition of Context and the support for stacks. But I was missing a function where you could easily check if a certain value actually is within a stack. It's basically just adding in_array() support for the stacks.

You could use it as follows:

# Normal
Context::push('foo', 'bar', 'lorem');

Context::in('foo', 'bar'); # true
Context::in('foo', 'doesNotExist'); # false

# Hidden
Context::pushHidden('foo', 'bar', 'lorem');

Context::inHidden('foo', 'bar'); # true
Context::inHidden('foo', 'doesNotExist'); # false

[KaniRobinson]

This is really cool! Very handy for when you're building analytics around contextual requests, or pulling out trends.

[lessevv]

A thought that just passed my mind, I could possibly also make the $strict an optional passable parameter for the in_array. Where it's non-strict by default, but can be made strict by passing true.

Not sure if that's needed, though.

[KaniRobinson]

An optional parameter isn't going to be breaking, I'd go for it.

This would be super useful in pulse!

[lessevv]

Added it, and a test to ensure strictness works!

[timacdonald]

I wonder if in is too generic. Feels like you are checking that the key is in the context.

Wonder if Context::stackContains might be better.

That also has symmetry with the Collection::contains method. It could accept a closure so that you can do more complex checks if needed.

Context::stackContains($stack, $value);

Context::stackContains($stack, function ($value) {
    // ...
});

That way we don't need the strict flag either, as the closure gives you that escape hatch.

[lessevv]

I would indeed be more inclined to go this way if the underlying stack was a collection, but it seems to be a deliberate choice to have this as an array. As the rest of the functions, such as has() do an array_key_exists(), I would say the current implementation is more true to the current implementation of Context in general.

Not necessarily shooting this down, but I feel this is more something for down the line if (if ever) Context receives a bit of a bigger update.

[timacdonald]

I've proposed a change to the closure based functionality in #52381