Tagged URLs to no longer trigger by default when no tag is identified to match against

[caronc]

🪲 Describe the Enhancement
Make it so tag(s) assigned to an (Apprise) URL exclusively become locked to it. As a result: no longer notify the applicable services unless the matching tags have been specified.

By default if no tags are associated on the CLI (or within API): All of the services are notified. After this change, this would no longer be the case.

• Only tagged URLs will be notified when the tag is specified.
• URLs that contain no tags will still be notified under default circumstances (where no tag is also specified).
• URLs that contain no tags will not be notified if a tag is specified. This is already the state the system operates in today. This point is to just note that this part will remain as is.

💡 Additional thoughts/ideas
To still allow backwards compatibility and have the ability to notify everything (even those with tags):

1. (optional idea) Introduce a default reserved tag name such as all that when specified matches against all URLs regardless of their other defined tags. These would also match against URLs that have no tags assigned to them.
2. (optional idea) Introduce a means (via the CLI) of listing which notification servers match a tag (without actually notifying them).
   • The matched URLs should substitute sensitive information (such as the apikey, tokens, passwords, etc) with a series of asterisks (*) before displaying the matched URL to the screen.

💡 Concerns
This is a bit of a breaking feature; as those adjusted to the current way things operate WILL be impacted by this change. Changes to be stretched over a release or two giving users ample time to adjust. This will involve:

• Sticking deprecation warnings on services notified that contain tags but were notified because no tags were identified.

[dkozinn]

I like both of the optional ideas, particularly #2 which beats getting piles of notifications while testing. For some service which use a pay-per-alert model, this could be extremely valuable.

[caronc]

I've implemented all of the above (including optional stuff) except:

The matched URLs should substitute sensitive information (such as the apikey, tokens, passwords, etc) with a series of asterisks (*) before displaying the matched URL to the screen.

As of now, if you use the new --dry-run (or -d) switch I added, it prints the full URL (with private tokens and/or passwords exposed). This is a rather big task to fix as I need to update all 48+ notifications to include some kind of privacy guard on the url() call. As a result, I think I'm going to accomplish this task in another pull request.

Sticking deprecation warnings on services notified that contain tags but were notified because no tags were identified.

This isn't as intuitive or easy to do as it is write in this ticket. 😉 . I strongly believe Apprise should have lead with this functionality from day 1. I'm not sure how many people are tagging their URLs and then calling the Apprise CLI without referencing the tags they just set. I'm going to assume that while this is kind of a breaking change; it shouldn't hit that large of a population...(famous last words)... but I'm choosing not to do the deprecation changes.

[caronc]

Issue has been addressed; closing