exchanges/margin: Fix marshalling issue

[gloriousCode]

PR Description

Addresses issue #1810

There is a bug from a lack of MarshalJSON implementation. When unmarshalling and marshalling an order.Submit for example, it will fail from being unable to parse a string into a margin.Type

Type of change

• Bug fix (non-breaking change which fixes an issue)

How has this been tested

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration and
also consider improving test coverage whilst working on a certain feature or package.

• go test ./... -race
• golangci-lint run
• TestUnmarshalOrder
• TestMarshalJSON

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation and regenerated documentation via the documentation tool
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally and on Github Actions with my changes
• Any dependent changes have been merged and published in downstream modules

[shazbert]

tACK. Was wondering about the delimiter and maybe we should add in one in a marshaller for Submit if missing between, but out of scope.

[gbjk]

Code looks good to me, nice work 👍

I've raised nits, but none of them stop this being merged as-is.

[gbjk]

Opinionated Nit:
As someone who runs tests verbose often, I really don't like having t.Run for trivial cases like this, over just adding tc.want to the end of the 2 checks, because of the increased output if we're always doing this.
I feel like we want t.Run for tests which are going to take a lot of time, or where we might want to -run them individually.

The reason I raise this (again) is because if we keep adding it for ubiqutous methods like TestMarshal or TestString then we'll get a lot of this:

=== RUN   TestMarshalJSON
=== PAUSE TestMarshalJSON
=== CONT  TestMarshalJSON
=== RUN   TestMarshalJSON/"isolated"
=== PAUSE TestMarshalJSON/"isolated"
=== RUN   TestMarshalJSON/"multi"
=== PAUSE TestMarshalJSON/"multi"
=== RUN   TestMarshalJSON/"cash"
=== PAUSE TestMarshalJSON/"cash"
=== RUN   TestMarshalJSON/"spot_isolated"
=== PAUSE TestMarshalJSON/"spot_isolated"
=== RUN   TestMarshalJSON/"unknown"
=== PAUSE TestMarshalJSON/"unknown"
=== RUN   TestMarshalJSON/""
=== PAUSE TestMarshalJSON/""
=== CONT  TestMarshalJSON/"isolated"
=== CONT  TestMarshalJSON/"cash"
=== CONT  TestMarshalJSON/"multi"
=== CONT  TestMarshalJSON/"spot_isolated"
=== CONT  TestMarshalJSON/""
=== CONT  TestMarshalJSON/"unknown"
--- PASS: TestMarshalJSON (0.00s)
    --- PASS: TestMarshalJSON/"isolated" (0.00s)
    --- PASS: TestMarshalJSON/"cash" (0.00s)
    --- PASS: TestMarshalJSON/"multi" (0.00s)
    --- PASS: TestMarshalJSON/"spot_isolated" (0.00s)
    --- PASS: TestMarshalJSON/"" (0.00s)
    --- PASS: TestMarshalJSON/"unknown" (0.00s)
PASS
ok      github.com/thrasher-corp/gocryptotrader/exchanges/margin        0.519s

And it'll overwhelm scrollback and make grepping the test output harder.

[gloriousCode]

I don't think we should be changing test design to suit dislike of the kind of verbose output when verbose and because of increased scrolling. The issue is much closer to "golang outputs subtests in an ugly manner" than "this test design has negative impacts". I understand your desire and you can and do design your tests without it. I do utilise the sub test functionality, its especially handy when one fails, to debug into just one of them.

[gbjk]

I'll yield. I'll just stop using verbose as much as I do currently.
BTW, you noted already I assumed that there's obviously a performance hit for using t.Run, which you're accepting as "worth it".
It's only 0.05-0.1s for me, though, and pales in comparison to our tests in general.

[gbjk]

Nits:

• Think the regression can be moved into the reason we do the test
• But actually, I don't think we should have this regression test here (in isolation of any other field tests); We didn't fix anything in order.Submit at all, so the regression wouldn't be here.
• Also: Am I missing why we couldn't have just set MarginType in the original orderSumbit and let L2215 handle this?

Suggested change

	// Margin-type regression test
	orderSubmit.MarginType = margin.Multi
	jOrderSubmit, err = json.Marshal(orderSubmit)
	require.NoError(t, err)
	err = json.Unmarshal(jOrderSubmit, &os2)
	require.NoError(t, err)
	require.Equal(t, orderSubmit, os2)
	orderSubmit.MarginType = margin.Multi
	jOrderSubmit, err = json.Marshal(orderSubmit)
	require.NoError(t, err, "json.Marshal must not error")
	err = json.Unmarshal(jOrderSubmit, &os2)
	require.NoError(t, err)
	require.Equal(t, orderSubmit, os2, "order.Submit must unmarshal Margin.Type correctly")

[gloriousCode]

I don't really know what you want me to do with this comment sorry. Do you want me to remove the whole test because its resolved in the margin package?