Global cookies settings are not retained when a site is added/removed from the `shields down` block

Description

Found while testing https://github.com/brave/brave-browser/issues/12782 Cookies settings are not retained when a site is added/removed from the shields down block

Steps to Reproduce

Case 1:

1. clean profile 1.46.x
2. open nytimes.com site in an NTP
3. add nytimes to shield down block in brave://settings/content/braveShields
4. make sure shield is Down for nytimes.com
5. click on the shield icon for nytimes.com and make the shields Up
6. make sure shield is Up for nytimes.com
7. expand the advanced controls shield settings and look for the cookies settings
8. cookies settings is Allow all cookies but the global shield cookies settings is Block cross site cookies
9. global cookies settings are not retained

Case 2:

1. clean profile 1.46.x
2. add nytimes.com in shields down block under brave://settings/content/braveShields
3. open nytimes.com in an NTP and ensure that shield is down
4. remove the blocked site nytimes.com from brave://settings/content/braveShields
5. open nytimes.com tab and ensure shield is enabled and default shield settings are retained on nytimes.com
6. change the global shield settings (Trackers and ads = Aggressive, FF= Strict, may break sites and cookies = Disabled)
7. ensured that the updated global shield settings are retained for nytimes
8. add nytimes to shields down block in content settings
9. ensured nytimes shield is down
10. enable the shield for nytimes.com manually
11. ensured shield is enabled and default shield settings are retained on nytimes (steps 6 shield settings are retained)
12. change the global shield settings (Trackers and ads = Standard, FF= Standard and cookies = All)
13. open nytimes, the updated shield settings are not retained for cookies

Actual result:

Cookies settings are not retained when a site is added/removed from the shields down block

https://drive.google.com/file/d/1ZHYz488-D-nOKpITsRguIhwxNAJ4aSzk/view?usp=sharing

Expected result:

Cookies settings should be retained when a site is added/removed from the shields down block

Reproduces how often:

Easy

Brave version (brave://version info)

Brave	1.46.80 Chromium: 107.0.5304.68 (Official Build) beta (64-bit)
Revision	a4e93e89d3b3df1be22214603fba846ad0183ca5-refs/branch-heads/5304@{#991}
OS	Windows 10 Version 21H2 (Build 19044.2130)

Version/Channel Information:

• Can you reproduce this issue with the current release? NA
• Can you reproduce this issue with the beta channel? Yes
• Can you reproduce this issue with the nightly channel? Yes

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? NA
• Does the issue resolve itself when disabling Brave Rewards? NA
• Is the issue reproducible on the latest version of Chrome? NA

Miscellaneous Information:

cc: @brave/qa-team @rebron @spylogsster

[bridiver]

If I do [*.]nytimes.com in brave://settings/content/braveShields then I get shields down, but that is a different setting than what the shields panel controls

If I then re-enable nytimes in the shields panel, it shows shields up (because the more specific match for www.nytimes.com is shields up), but cookies are still (incorrectly) applied based on the [*.]nytimes.com entry

So… there are two bugs here:

1. We’re still showing the effective setting in the UI and that can be broken in all kinds of different ways. That change was supposed to be reverted
2. We’re applying [*.]nytimes.com to the effective cookies setting even though there’s a more specific setting www.nytimes.com that should take precedence

[GeetaSarvadnya]

@GeetaSarvadnya please use shields up/down terminology because “block” is confusing in this context. Also I assume “enable the shield manually” - means in the shields panel? Can you please update it to reflect that?

@bridiver Yes, in the shields panel, I will update the steps. Thanks!