#1170 allow json data in OneSignal template arguments

[phantom943]

Description:

Related issue (if applicable): #1170

Adds optional parameter to pass arbitrary data to via base64 encoding

[phantom943]

Full disclosure: I took the liberty to disable flake8 in the tests directory, because to me it does not make sense to maintain or require code style in tests. @caronc If you are against this change - please let me know and I'll revert that commit.

[caronc]

Thank you for this PR. Is there reasson why decode wouldn't just be implied; would it feel more automated if b64: and == at the end was the trigger to do the decoding? I suppose your way though allows for the edge case that people may just want to send that string as is?

I'm not sure if i like that if the decoding fails, it just still gracefully sends the notification when it did in fact fail to decode it prior to. I feel as though the notification should fail to send... letting the user know they're data provided was bad. This might be more consistent with the rest of the application .

Also, I get the flake8 is a bit dated... i'll put in black soon but due to #1131 being such a massive change (still in progress), ill switch to black only after it's done. Then at least you can run black --fix and not have to deal with the problems manually.

for now though, i do want to keep the flake8 standards (as dated and annoying as they are), even for tests. I use vi, so i take for granted sometimes that flake8 is ran all the time for me and pointing things out as i go. I do get the frustration peole have here though...

on a side note, very interesting solution for passing non-string based data through Apprise with the base64 technique

[phantom943]

Hello @caronc!
Indeed it's more automated if it detects strings starting with b64:. But, as you correctly pointed out, without this safeguard it would be a breaking change where data passed via :parameters is treated differently from one version to another. The switch I added makes it opt-in instead of opt-out. Personally, I prefer all my software to add new functionality in an opt-in way so that I don't make people rewrite their code with a new version of 3rd party software. That was the motivation behind it.
In terms of the try: except: pass block with base64+JSON decode logic that I added: I was also hesitant at first on what to do if we fail to decode the string. But the logic I had was also the same: if there was a user legitimately passing a string :parameter=b64:mike for some reason, or the thing that's being encoded in base64 is NOT a JSON object (it could be an honest-to-god raw base64 encoded binary data, for all we know) - the application would not let them send the notification with that string. Maybe this warrants another switch ignore_decode_errors that would take a value of no (default, as you suggested) or yes allowing to send the notification regardless of the errors in that block? That makes the change even more complicated though - not sure if this is reasonable? What do you think?
In terms of tests - I respect your opinion and thanks for the fixes.
And in terms of the base64 solution as a whole: from my research, there are three semi-standard ways of dealing with arbitrary objects in the URL: base64, repeated arguments way (e.g. ?di=1&di=2&di=3 -> di=[1,2,3]) and building dictionary way (e.g. ?di[a]=1&di[b]=2 -> di={"a":1,"b":2}).
The second one is somewhat built into Python, but it's only partial meaning you can't really pass dictionaries that way.
The third one is quite comprehensive, but coding that one (without resorting to eval) would be a pain.
Hence, I chose the first one, albeit it being not the most elegant.

[caronc]

I'm good; thanks again for a great PR