orders: Add methods to derive SubmitResponse and Detail types.

[shazbert]

PR Description

• Construct order.SubmitResponse from order.Submit struct
• Construct order.Detail from order.SubmitResponse struct
• Rename ID field to OrderID to be explicit as there were a lot of different ID's on order types.

Fixes # (issue)

Type of change

Please delete options that are not relevant and add an x in [] as item is complete.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

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
• Test X

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/AppVeyor with my changes
• Any dependent changes have been merged and published in downstream modules

[gloriousCode]

I'm not sure about this feature. At face value it seems like an improvement, but I think it comes across incorrectly.

Many API's do not return full order details from a submit request and if it does, you are not taking in those details in the order.Detail response due to how limited Derive is. Some order API responses are even just an order ID or "success". Returning an order.Detail can give a false impression of how the order was handled since its made from an order.Submit and not from the exchange's details.

A SubmitResponse contains enough information to then get the full order details from the exchange without the impression its the order

Also, please fix your tests and linting

[gloriousCode]

Thanks for making those changes! I'm glad the only place in GCT to DeriveDetail is with the order manager. The nits are now mostly minor, with exception to the backtester which you destroyed 💥

[gloriousCode]

Unrelated, this may no longer return a slice of orders: https://www.btse.com/apiexplorer/spot/#placeorder

[shazbert]

Yeah Agreed, I don't have any keys or funds on that exchange to verify.

[thrasher-]

Can confirm that the current implementation is correct:

[{"status":2,"symbol":"BTC-USDT","orderType":76,"price":25000.0,"side":"BUY","size":1.0E-5,"orderID":"cfd6680d-ba2d-49e5-9b07-460f5758ced3","timestamp":1654479079883,"triggerPrice":0.0,"stopPrice":null,"trigger":false,"message":"","averageFillPrice":0.0,"fillSize":0.0,"clOrderID":null,"stealth":1.0,"deviation":1.0,"postOnly":false,"originalSize":1.0E-5,"remainingSize":1.0E-5,"time_in_force":"GTC"}]

{Exchange:BTSE Type:LIMIT Side:BUY Pair:BTCUSDT AssetType:spot ImmediateOrCancel:false FillOrKill:false PostOnly:false ReduceOnly:false Leverage:0 Price:25000 Amount:1e-05 QuoteAmount:0 TriggerPrice:0 ClientID: ClientOrderID: LastUpdated:2022-06-06 11:31:18.708066 +1000 AEST m=+1.690237201 Date:2022-06-06 11:31:18.708066 +1000 AEST m=+1.690237201 Status:NEW OrderID:cfd6680d-ba2d-49e5-9b07-460f5758ced3 Trades:[] Fee:0 Cost:0}

[gloriousCode]

Two tiny nits and I think its all GEE

[gloriousCode]

Thank you for dealing with my requests! tACK!

[thrasher-]

tACK! Thanks for fixing the exchange_template issue