add DecodeBytes function, refactor tests

[julijane]

While it is only a two liner, it feels inconsistent to have a DecodeBase64 and a DecodeHex function, but not a DecodeBytes function. This PR adds that.

I'm wondering if the tests for DecodeBase64, DecodeHex and DecodeBytes should actually have a single shared table of test cases?

[blahspam]

I think you're right. Merging all DecodeXXX tests makes a lot of sense. Mind tackling that in this PR?

[julijane]

Sure, I can do that. Question: How do you think it should be done, i'm now not sure?

Option a.) Have each testcase have the input as base64, as hex and as a slice of bytes.
Option b.) Just have one, for example base64, and convert it in the test to the required format.

I was thinking of Option b.) as Option a.) seems extensive, but then again it would make it a bit questionable to have tests for more than one of the functions in the first place (but it counts as test coverage I guess). Probably doing Option a.) is the best bet against the encoding/decoding breaking (but do we expect to have go's base64 or hex en/decoding to ever break?)

So what do you prefer?

[blahspam]

Yeah I think option b is the better of the two. The test case can then detect whether its a base64 or hex string and decode and validate accordingly.

[julijane]

Well, after I have been thinking a bit more about this (and before you replied), I had now chosen option a.), because it makes this more independent. WDYT?

[blahspam]

I'm good with that.

[julijane]

Well, then this can be merged :) I first thought there were two more test cases that should be integrated, but that does not work, so I had deleted my comment regarding this again.