extracted the duplicated logic of the 2 json extensions into this re-usable class - which should also work for other methods using INT-bitwise flags.

After this PR is merged, we can use this new service in other extensions which also do bitwise flag stuff

the actual fix for the bug 6654 was the missing UnionType handling

Even if the constant is not known by the ReflectionProvider, we could support this case for AST-driven analysis. If the expression is ConstFetch of $constName or even a bitwise combination where one of the parts is $constName, we can return Yes.

I am not sure what todo with this feedback.

do you mean we should add AST-driven analysis with this PR? or in a future PR?

when the ReflectionProvider doesn't know the constant, and we therefore cannot judge what the value-type of the constant is (is it a string? is it a int? which constant-int value has it), IMO we cannot analyse whether its contained in a given expression, can we? or would you judge the constant just by its name, no matter what the value is?

do you see this "constant is not know to the ReflectionProvider" as an essential case, or is it a edge case which can be done later?

I think it's just about an if that could easily be added. If we ask BitwiseFlagHelper about a FOO_CONSTANT and we see the AST contains a ConstFetch of FOO_CONSTANT, we don't need to verify the value because we know it's the same thing.

I think I figured it out