Merge ~pelpsi/launchpad:typeerror-unmarshall-non-string-objects into launchpad:master

I'm not sure about this. Do you know why we're returning an int in an allegedly text field in the first place? That seems like a type error that we should fix.

What type of value were we passing to the `obfuscated_email` function that caused the TypeError? I'm wondering since this is a `TextFieldMarshaller`...

It would be good to create a test that replicated the bug, i.e., a test that makes a request that would have led to the TypeError.

> I'm not sure about this. Do you know why we're returning an int in an
> allegedly text field in the first place? That seems like a type error that we
> should fix.

The problem for core20 is caused by `'auto_build_channels':{'_byarch': {'riscv64': {'snapcraft': 'beta'}}}` because we are trying to unmarshall `{'riscv64': {'snapcraft': 'beta'}}` that is not a string.

For core22 we have instead `"auto_build_channels": {"snapcraft": "stable/launchpad-buildd"}` and we can successfully unmarshall "stable/launchpad-buildd"

I'm not sure if it is correct to have a nested dictionary in "auto_build_channels"

> What type of value were we passing to the `obfuscated_email` function that
> caused the TypeError? I'm wondering since this is a `TextFieldMarshaller`...
>
> It would be good to create a test that replicated the bug, i.e., a test that
> makes a request that would have led to the TypeError.

Sure, I can push the test I created during the investigation.
I will put it in `lp.snappy.browser.tests.test_snap`

Moreover you will get a similar error ( https://oops.canonical.com/oops/?oopsid=OOPS-f72a3fae0ab34f1607dfbd203f5b274a ) navigating `https://launchpad.net/~ubuntu-core-service/+snap/core20` in incognito mode, that's because we call the obfuscation in that case.

In this specific case is a little bit different because we are using json.dump on the cache but the error is pretty much the same, we are not recursively iterating on the dictionary and the obfuscation method fails

In that case, I think the correct fix would be to weaken `value_type` in the constructor for `SnapBuildChannelsField` instead. It's legitimate for the channels dict to contain a `_byarch` member which is then used to select different behaviour depending on the architecture (see `Snap.requestBuildsFromJob`).

I think the reasonable choices are (1) to just drop `value_type` entirely and leave the dict values unvalidated, or (2) to figure out how to implement custom validation here that validates `_byarch` values as dictionaries mapping architecture names to the current definition of `SnapBuildChannelsField`, and any other values to `TextLine`. The stricter typing in (2) is probably more desirable, but I'm not sure whether it will turn out to be an unreasonable amount of work.

I think that we can choose the (1) to push a quick fix and then we can open a ticket to implement the stricter typing (2) to have a more elegant solution. What do you think ?

I'm fine with that.

Implemented agreed changes and added new test cases

Before you land this, please use `git rebase -i` or similar to amend the history to remove the commit that you reverted.

Oh, also please update the overall commit message of this MP.

Thank you Colin for the review, I squashed commits into one and I updated the commit message