[DEVOPS-985] add useStackBinaries parameter to default.nix

[disassembler]

Description

This adds a top level argument to cardano-sl nix to useStackBinaries. By passing this argument, None of the nix built cardano binaries are used or even in the dependency tree. All this requires is nix to be installed to generate scripts developers can run to:

1. run a wallet against any environments supported by the scripts
2. override wallet configs for custom settings (see https://github.com/input-output-hk/cardano-sl/blob/develop/docs/exchange-onboarding.md#generate-custom-configuration)
3. run a full demo cluster with 4 core nodes, 1 relay and 1 wallet
4. run the wallet integration test suite against demo cluster listed in 3.

The way this works is if useStackBinaries is specified, the binary being executed that normal comes from iohkPkgs built by nix is prefixed with stack exec -- and those binaries are removed from the nix dependency tree. Essentially, it treats the binaries as strings and prepends a string making for super fast nix builds and shifting the burden to stack at run-time.

To test you need:

1. stack in your PATH

2. be in the root of the cardano-sl repo

3. run any of the following, or read the exchange docs for more complex examples:

   • nix-build -A connectScripts.mainnet.wallet -o launch_mainnet_wallet_stack --arg useStackBinaries true && ./launch_mainnet_wallet_stack
   • nix-build -A demoCluster -o launch_demo_cluster_stack --arg useStackBinaries true && ./launch_demo_cluster_stack
   • nix-build -A walletIntegrationTests -o wallet_integration_tests_stack --arg useStackBinaries true && ./wallet_integration_tests_stack

One final note, since these are not run in an isolated sandbox, there is a potential of your system interfering with the behavior. For example, If walletIntegrationTests throws SSL errors, there's a good chance you have a wallet already listening on port 8090.

Linked issue

https://iohk.myjetbrains.com/youtrack/issue/DEVOPS-985

Type of change

• 🐞 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 change)
• 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
• 🔨 New or improved tests for existing code
• ⛑ git-flow chore (backport, hotfix, etc)

Developer checklist

• I have read the style guide document, and my code follows the code style of this project.
• If my code deals with exceptions, it follows the guidelines.
• I have updated any documentation accordingly, if needed. Documentation changes can be reflected in opening a PR on cardanodocs.com, amending the inline Haddock comments, any relevant README file or one of the document listed in the docs directory.

Testing checklist

• I have added tests to cover my changes.
• All new and existing tests passed.

QA Steps

Screenshots (if available)

[KtorZ]

Looks like something we wanted for a long time :D