Add support for OR in block visibility conditions

Please also note, I fixed in this Version :

• Missing context vs. context value, a cache issue, as stated in the comment in code.
• The conditions count was created prior the and-or plugin was removed.
• The form
• I applied the same logic in the radio negate switch form to all considerable elements in the form.
• I choose to stick to jQuery in block.js

One further opinion on this ... the check regarding the empty request_path plugin - shouldn't it be happen in the plugin form validation method instead. It is called a few lines below where the check was added.

Sorry, still found a tiny JavaScript selector issue. I will not start the failed tests in 78 again, as nothing has changed.
Can please sb. take care of the functional test, who has some strong suites there.

One final thought on this - the original code is right in one further thing: The Condition should be added to the conditions array in every case, even if there is an exception, so when collecting cachability, every condition is applied to forbidden for missing value, not just only the valid ones. Adding another version here, which fixes this.

Fixed CCF for #81 in 9.5.x.

I think that having one condition logic for all visibility types is wrong.
"user roles" condition should be always in AND mode.

user roles is different from "content type" or "path".

i suggest to separate "user role" from other conditions.
I think the better solution is to have

Visibility (AND or OR for all conditions)

AND

User Visibility (AND or OR for all conditions relative to user)

Thank you

@ #82: This is a restriction imho: why?
I could say we should leave it more general, as you can't exclude in advance an OR condition on user role.

Here is an example usecase for a block showing diff/debug/editorial information:

1. Show this block on taxonomy term pages only
   
   AND
2. Show this block on admin or edit pages only
   
   OR
3. Show this block if user has taxonomy editor role

Is it possible to have this use case?

1. show A block on taxonomy term
OR
2. show A block on /my-custom-url

3. show in the previous page only if user is admin

thank you

Attached bellow is the adopted patch for 10.2.x.

Added patch for 11.x

CCF error

Tried fixing CCF, attached interdiff for same.

Caused a large number of failures.

Tryed Patch #86 on a 10.2.x Drupal Page. Patch does apply, but when i try to configure a block on the blocklayout page, it fails with "Error: Undefined constant "Drupal\block\form_state" in Drupal\block\BlockForm->buildVisibilityInterface() (line 242 of core/modules/block/src/BlockForm.php)."

Fixed the patch that applies against 10.2.x.

Patch for 10.2.x

Hiding patches for clarity

Cleaned up issue summary so removing that tag.

Ran test-only feature and got https://git.drupalcode.org/issue/drupal-923934/-/jobs/1210671 but that shows the schema update

This shows the block placement test. https://git.drupalcode.org/issue/drupal-923934/-/jobs/1211130

So removing that tag as well

Turned patch #93 into an MR with a few changes
Removed some changes to the tests that seemed out of scope.
Turned the new condition into an attribute vs annotation usage.
Added new test coverage.

Suggestions appreciated

Posted in slack and @berdir made a recommendation to take a deeper look at #59

smustgrave → closed merge request !7270

Updated issue summary with new solution.

I've pushed changes to the new MR but there is a test failure I can't figure out why, with the default config.

All tests green, think ready for review of new approach.

Left some comments on the MR, IMO the summary could use a rewording - it took me a few goes to understand what "hit" meant in this context.

Updated and cleaned out more to just include a single example.

Addressed feedback

Forgot the upgrade path test

#93 worked for me. Drupal version : 10.3.8

Merge request !7274 could not be applied.

Drupal 10.4.1 adapted patch.

#106 missed the plugin itself.

Drupal 10.4.2 patch—working.

This will need the same preSave logic that was requested over in https://git.drupalcode.org/project/drupal/-/merge_requests/6953#note_463274

I haven't figured out how to persist the deprecationEnabled setting between the update hook and preSave but https://git.drupalcode.org/project/drupal/-/merge_requests/5544/diffs is using similar logic and its working there.