Add early versions of matchmake extension common methods

[shutterbug2000]

Still needs a lot to be done, not ready to be merged. As for how it works: You're expected to keep 2 copies of the MatchmakeSession in the database: (we'll call them "working copy" and "search copy") Working copy represents the MatchmakeSession as it is given to the console in the response, and is what should be modified. Search copy represents the MatchmakeSession as it is used when searching for a match. This should only be modified to remove undesired search criteria (such as Splatfest power in Splatoon, or precise VR/BR in MK7), and modifications must be performed the same way when both searching for a match (to the search MatchmakeSession) and when making a match (to the saved search copy).

[jonbarrow]

I noticed this protocol doesn't follow the same conventions as the common secure and common authentication protocols?

In those protocols the "common" protocol struct embeds the original protocol from nex-protocols-go inside it and extends it's methods, like so:

type CommonAuthenticationProtocol struct {
    *nexproto.AuthenticationProtocol
    server                 *nex.Server
    secureStationURL       *nex.StationURL
    buildName              string
    passwordFromPIDHandler func(pid uint32) (string, uint32)
}

Doing it this way makes it so game servers only need to call:

authenticationProtocol := authentication.NewCommonAuthenticationProtocol(nexServer)

And now authenticationProtocol has access to all our custom methods and it has the benefit of having access to the original protocol methods so it can overwrite any handlers set in common (if need be)

[jonbarrow]

I noticed a lot of hard-coded hex strings like 0017000000, and B90B0000, and (a long one) 000008005f00000000000000000a000000000000010000035c01000001000000060000008108020107000000020000000100000010000000000000000101000000d4000000088100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ea801c8b0000000000010100410000000010011c010000006420000000161466a08c8df18b118ed5a67650a47435f081d09804a7c1902b145e18eff47c00000000001c000000020000000400405352000301050040474952000103000000000000008f7e9e961f000000010000000000000000

Do we have ANY idea what these mean?

They are also repeated several times in the protocol. I think breaking these out into global variables would make things a bit cleaner? You can add a globals package to the protocol similar to the globals package in friends-secure. Then you can import the package using github.com/PretendoNetwork/nex-protocols-common-go/matchmake_extension/globals and use the variables anywhere in the protocol

I also see a lot of manual hex string manipulation, this can likely be made a bit cleaner using the nex-go StreamIn and StreamOut types. These implement Crunch under the hood

And one last thing I noticed is that there's some style issues. Go's style guide says things like pid should be written as PID

[shutterbug2000]

This PR is obsolete, closing.