Engine QA (#381)

* 1) Update Dockerfile/docker-compose.yml
2) Remove inline strings for buy/sell/test pairs
3) Remove dangerous order submission values
4) Fix consistency with audit_events (all other spec files use
CamelCase)
5) Update web websocket endpoint
6) Fix main param set (and induce dryrun mode on specific command line
params)

* Engine QA

Link up exchange syncer to cmd params, disarm market selling bombs and fix OKEX endpoints

* Fix linter issue after merge

* Engine QA changes

Template updates
Wrapper code cleanup
Disarmed order bombs
Documentation updates

* Daily engine QA

Bitstamp improvements
Spelling mistakes
Add Coinbene exchange to support list
Protect API authenticated calls for Coinbene/LBank

* Engine QA changes

Fix exchange_wrapper_coverage tool
Add SupportsAsset to exchange interface
Fix inline string usage and add BCH withdrawal support

* Engine QA

Fix Bitstamp types
Inform user of errors when parsing time accross the codebase
Change time parsing warnings to errors (as they are)
Update markdown docs [with linter fixes]

* Engine QA changes

1) Add test for dryrunParamInteraction
2) Disarm OKCoin/OKEX bombs if someone accidently sets canManipulateRealOrders to true and runs all package tests
3) Actually check exchange setup errors for BTSE and Coinbene, plus address this in the wrapper template
4) Hardcode missing/non-retrievable contributors and bump the contributors
5) Convert numbers/strings to meaningful types in Bitstamp and OKEX
6) If WS is supported for the exchange wrapper template, preset authWebsocketSupport var

* Fix the shadow people

* Link the SyncContinuously paramerino

* Also show SyncContinuously in engine.PrintSettings

* Address nitterinos and use correct filepath for logs

* Bitstamp: Extract ALL THE APM

* Fix additional nitterinos

* Fix time parsing error for Bittrex

.github/CONTRIBUTING.md

@@ -17,6 +17,7 @@ In order to maintain a consistent style across the codebase, the following codin
 - In line with gofmt, for loops and if statements don't require parenthesis.
 
 Block style example:
+
 ```go
 func SendHTTPRequest(method, path string, headers map[string]string, body io.Reader) (string, error) {
     result := strings.ToUpper(method)
@@ -38,51 +39,51 @@ func SendHTTPRequest(method, path string, headers map[string]string, body io.Rea
 ```
 
 ## Effective Go Guidelines
+
 [CodeLingo](https://codelingo.io) automatically checks every pull request against the following guidelines from [Effective Go](https://golang.org/doc/effective_go.html).
 
-
 ### Comment First Word as Subject
+
 Doc comments work best as complete sentences, which allow a wide variety of automated presentations.
 The first sentence should be a one-sentence summary that starts with the name being declared.
 
-
 ### Good Package Name
-It's helpful if everyone using the package can use the same name 
-to refer to its contents, which implies that the package name should 
-be good: short, concise, evocative. By convention, packages are 
-given lower case, single-word names; there should be no need for 
-underscores or mixedCaps. Err on the side of brevity, since everyone 
-using your package will be typing that name. And don't worry about 
-collisions a priori. The package name is only the default name for 
-imports; it need not be unique across all source code, and in the 
-rare case of a collision the importing package can choose a different 
-name to use locally. In any case, confusion is rare because the file 
+
+It's helpful if everyone using the package can use the same name
+to refer to its contents, which implies that the package name should
+be good: short, concise, evocative. By convention, packages are
+given lower case, single-word names; there should be no need for
+underscores or mixedCaps. Err on the side of brevity, since everyone
+using your package will be typing that name. And don't worry about
+collisions a priori. The package name is only the default name for
+imports; it need not be unique across all source code, and in the
+rare case of a collision the importing package can choose a different
+name to use locally. In any case, confusion is rare because the file
 name in the import determines just which package is being used.
 
-
 ### Package Comment
-Every package should have a package comment, a block comment preceding the package clause. 
-For multi-file packages, the package comment only needs to be present in one file, and any one will do. 
-The package comment should introduce the package and provide information relevant to the package as a 
+
+Every package should have a package comment, a block comment preceding the package clause.
+For multi-file packages, the package comment only needs to be present in one file, and any one will do.
+The package comment should introduce the package and provide information relevant to the package as a
 whole. It will appear first on the godoc page and should set up the detailed documentation that follows.
 
-
 ### Single Method Interface Name
-By convention, one-method interfaces are named by the method name plus an -er suffix 
+
+By convention, one-method interfaces are named by the method name plus an -er suffix
 or similar modification to construct an agent noun: Reader, Writer, Formatter, CloseNotifier etc.
 
-There are a number of such names and it's productive to honor them and the function names they capture. 
-Read, Write, Close, Flush, String and so on have canonical signatures and meanings. To avoid confusion, 
-don't give your method one of those names unless it has the same signature and meaning. Conversely, 
-if your type implements a method with the same meaning as a method on a well-known type, give it the 
+There are a number of such names and it's productive to honor them and the function names they capture.
+Read, Write, Close, Flush, String and so on have canonical signatures and meanings. To avoid confusion,
+don't give your method one of those names unless it has the same signature and meaning. Conversely,
+if your type implements a method with the same meaning as a method on a well-known type, give it the
 same name and signature; call your string-converter method String not ToString.
 
-
 ### Avoid Annotations in Comments
-Comments do not need extra formatting such as banners of stars. The generated output
-may not even be presented in a fixed-width font, so don't depend on spacing for alignment—godoc, 
-like gofmt, takes care of that. The comments are uninterpreted plain text, so HTML and other 
-annotations such as _this_ will reproduce verbatim and should not be used. One adjustment godoc 
-does do is to display indented text in a fixed-width font, suitable for program snippets. 
-The package comment for the fmt package uses this to good effect.
 
+Comments do not need extra formatting such as banners of stars. The generated output
+may not even be presented in a fixed-width font, so don't depend on spacing for alignment—godoc,
+like gofmt, takes care of that. The comments are uninterpreted plain text, so HTML and other
+annotations such as _this_ will reproduce verbatim and should not be used. One adjustment godoc
+does do is to display indented text in a fixed-width font, suitable for program snippets.
+The package comment for the fmt package uses this to good effect.

.github/CONTRIBUTING_TEMPLATE.md

@@ -17,6 +17,7 @@ In order to maintain a consistent style across the codebase, the following codin
 - In line with gofmt, for loops and if statements don't require parenthesis.
 
 Block style example:
+
 ```go
 func SendHTTPRequest(method, path string, headers map[string]string, body io.Reader) (string, error) {
     result := strings.ToUpper(method)
@@ -38,9 +39,12 @@ func SendHTTPRequest(method, path string, headers map[string]string, body io.Rea
 ```
 
 ## Effective Go Guidelines
+
 [CodeLingo](https://codelingo.io) automatically checks every pull request against the following guidelines from [Effective Go](https://golang.org/doc/effective_go.html).
 
 {{range .}}
+
 ### {{.title}}
+
 {{.body}}
-{{end}}
+{{end}}

.github/ISSUE_TEMPLATE.md

@@ -30,4 +30,4 @@ Please provide detailed steps for reproducing the issue.
 
 ### Failure Logs
 
-By default, GoCryptoTrader stores its `debug.log` file in `%APPDATA%\GoCryptoTrader` on Windows and `~/.gocryptotrader` on Linux/Unix/macOS. Raw text or a link to a pastebin type site is preferred.
+By default and if file logging is enabled, GoCryptoTrader stores its `log.txt` file in `%APPDATA%\GoCryptoTrader\logs` on Windows and `~/.gocryptotrader/logs` on Linux/Unix/macOS. Raw text or a link to a pastebin type site is preferred.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,6 @@
-# Description
+# PR Description
 
-Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. 
+Please include a summary of the change, feature or issue which this pull request addresses. Please also include relevant motivation and context. List any dependencies that are required for this change.
 
 Fixes # (issue)
 
@@ -13,22 +13,22 @@ Please delete options that are not relevant and add an `x` in `[]` as item is co
 - [ ] 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?
+## 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
+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.
 
-## Please also consider improving test coverage whilst working on a certain package
+- [ ] go test ./... -race
+- [ ] golangci-lint run
+- [ ] Test X
 
-- [ ] Test A
-- [ ] Test B
-
-# Checklist:
+## 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 
+- [ ] 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 Travis with my changes
-- [ ] Any dependent changes have been merged and published in downstream modules
+- [ ] Any dependent changes have been merged and published in downstream modules