When request is blocked by a user filter rule, unblock should uncheck/delete it

[ameshkov]

We now allow the user to add a new "unblocking" rule.

Instead, for user filter rule, we could offer more options:

1. Unblock with a rule
2. Disable user filter rule
3. Delete user filter rule

Not sure about disabling/deleting, I guess we should stick to a single thing (either deleting or disabling)

TODO: We should re-think this, see the comment: #1380 (comment)

[TPS]

This is particularly awful in latest v3ß. When I press "Unblock" I want create a @@ rule, not delete my blocking rule! A menu presenting additional options is ok!

[ameshkov]

In this case, we'll quickly spam the user filter with all kinds of rules and this is exactly what we want to avoid.

I guess a compromise would be to disable a rule instead of deleting it.

[TPS]

I'm the user, right? If I want to spam my own user filterlist, let me. But y'all might suggest it'd be better to delete/disable/modify the rule in a particular fashion than forcing it.

Also, if complexity of that user list is a problem, maybe suggest ways to trim if it hits a threshold (say, 100 rules — I'm 4× that already 😅), like deleting rules that duplicate others, especially from subscribed filterlists.

[ameshkov]

The problem with the old approach is simple.

1. Imagine you block an URL;
2. Then, sometime later you unblock it via adding a new unblocking rule to the user filter;
3. And next time when you want to block it back, you simply cannot because you already have an unblocking rule in the user filter;

The only solution is to modify user filter rules, not create new ones.

On the other hand, there's a new issue introduced by this. You can block the whole example.org and would like to unblock example.org/good-stuff/* only.

@admitrevskiy let's rollback to the previous behavior for now.

[TPS]

Thanks! I agree, that is a problem. Maybe keep old behavior as advanced menu toggle, & variation of new behavior as newbie default?