Add w3_validate_<type name> functions

[MartinSStewart]

This PR adds support for w3_validate_<type name>: <type name> -> Result String () functions. These are user defined functions that w3_decode_<type name> functions will use to determine if a custom type can safely be decoded.

Here's an example of what w3_validate looks like in real code

module PersonName exposing (PersonName(..), fromString, fromStringLossy, maxLength, toString)

import String.Nonempty exposing (NonemptyString(..))


type PersonName
    = PersonName NonemptyString


maxLength : number
maxLength =
    32


fromString : String -> Result String PersonName
fromString text =
    case String.trim text |> String.Nonempty.fromString of
        Just nonempty ->
            if String.Nonempty.length nonempty > maxLength then
                Err "Too long"

            else if String.Nonempty.any (\char -> char == '\n' || char == '\u{000D}' || char == '@') nonempty then
                Err "Name can't contain line breaks or @ symbol"

            else
                PersonName nonempty |> Ok

        Nothing ->
            Err "Can't be empty"


w3_validate_PersonName : PersonName -> Result String ()
w3_validate_PersonName (PersonName text) =
    fromString (String.Nonempty.toString text) |> Result.map (\_ -> ())


toString : PersonName -> String
toString (PersonName a) =
    String.Nonempty.toString a

Motivation behind this feature

If you have an opaque type that only can be constructed via a function that enforces some guarantee (perhaps a type Name = Name String that can't be longer than 100 characters) then you might expect that guarantee to hold when you serialize data. The reality however is that w3_decode functions circumvent any opaque type guarantees and just create a instance of the type directly. This means a hacker could manually create a ToBackend request that contains an opaque type that violates some guarantee that type is supposed to have. Since the backend is probably coded with the assumption that opaque type guarantees hold, this could lead to bugs or security vulnerabilities.

Drawbacks

This feature has a number of drawbacks.

• The user can potentially mess up their w3_validate_<type name> implementation such that it returns Err "some error" for values that can be created normally. If those values get sent to the backend then the decoder will fail and the request will get silently dropped (the "some error" will get logged on the Lamdera server but that's it)
• w3_validate functions will confuse tools like IDEs and elm-review (until patches are made) since they will appear like unused functions
• The current implementation of this feature doesn't allow w3_validate function to be defined and a w3_decode/encode function to be referenced by the user in the same module. This could be solved but for now isn't due to implementation complexity. I think in practice it won't be an issue since the user rarely references w3_decode/encode functions and if they do, they can easily just do that in a separate module.

w3_unsafe_decode

• There are now w3_unsafe_decode_<type name> functions that are generated along side w3_decode. These behave identically to how w3_decode behaved before this PR (or how w3_decode behaves now if the user has not written any w3_validate functions)
• For Lamdera infrastructure, w3_unsafe_decode is intended to be always used except for ToBackend decoding. The reasoning is that we want to prevent a hacker from sending invalid data to the backend. But if we get invalid data some other way (perhaps the user has changed the validation function between migrations and old data is decoded with a new more strict w3_validate function) then it's better to just let it through since the alternative could be a backup failing to load or the backend failing to communicate with the frontend.
• Note that we still need to make some changes to lamdera infrastructure so that they use w3_unsafe_decode since the code isn't all located in lamdera/compiler.

In conclusion, I'm not particularly happy with this feature, but I don't know of any better way to solve the motivating security issue. I've spoken with a couple people and brainstormed ideas and this seems like the best option.