Add Github Dev Containers

[Findeton]

Parent issue: https://github.com/sequentech/meta/issues/8

This PR configures a dev container for the project. The main idea is to make it easy to start developing the project.

Our initial objective was to always use an x86_64 environment, but apparently this isn't possible in aarch64 architectures yet. Another option was to use x86_64 by using Github Codespaces but Codespaces doesn't support Nix yet. So we decided to use docker images that use the same architecture as the host.

We wanted to use the nix-devcontainer project/docker image as a base but the image is not configured for aarch64 systems either so I used their code as a base to create our Dockerfile. In the future we can use nix-devcontainer if they add aarch64 support or we can define our own reusable docker container in multiple projects.

As we normally develop on M1 machines, we wanted to add a github action that runs an aarch64 machine, but there are no github-hosted m1 machines yet (it's on their roadmap though).

We haven't configured git commits to enable signing from the dev container, but as it doesn't work on Codespaces yet you can do it from a local terminal.

Changes

• Add dev container configuration
• Update the Readme to explain how to use dev containers and its limitations.
• Update NixOS/nixpkgs version and flake.lock to avoid broken openssl package.
• Added pkgs.binaryento the flake dev shell to fix issue on dev container.
• Updated license github action to run from nix develop.

[edulix]

Nice work! Please, create an isssue upstream and link it in the Sequent Development Board (SDB) or link to the existing issues upsteam in the SDB to track them:

1. I've added already to the SDB (and self-subscribed to the tickets for tracking) and set in the backlog:

• GitHub Actions: Apple Silicon (M1) powered macOS runners (Public Beta) github/roadmap#528
• Nix doesn't work in Github Codespaces NixOS/nix#6680

2. Create an issue to support aarch64 in nix-devcontainers
3. is any issue related to using docker in arm with x86_64 to be tracked?

[edulix]

Just for the record, I want to write here some issues to be resolved later and improvements that can be made, maybe we could also create tracking tickets for those:

• When creating a terminal in VS Code, it says error: getting status of '/workspaces/strand/default.nix': No such file or directory. This is just direnv not working. Maybe we should try to do use_flake if possible https://github.com/nix-community/nix-direnv
• Probably related to the above, when loading the project in a container the developer gets a warning saying The nix environment is available in your workspace Source: Nix Environment Selector (Extension) and then two button Select and Dismiss. Everything should be configured already when the devcontainer loads, so this should not happen.
• When opening a rust file, I get Couldn't start client Rust Language Server Source: Rust (Extension) and also Rustup not available. Install from https://www.rustup.rs/.
• We could take advantage of the public https://sequentech.cachix.org/ cachix cache, so that building with nix build is faster inside the devcontainer.
• We could also use the cachix public cache when building the Dockerfile, otherwise everytime the project is build it downloads ~3GB of data and is quite slow.
• We should, additionally, mount a local /nix cache so that even with local code-changes or dependencies, a reload of the container is fast. Also, this will help us while using M1, since the cachix cache is currently only populated through github actions and github actions doesn't currently support aarch64 (m1) for Mac OS X.
• Debugging doesn't seem to work. I cannot create breakpoints (I use Run > Toggle Breakpoint but it doesn't seem to do anything), and when I click in Run > Start Debugging it shows a warning saying You don't have an extension for debugging Rust. Should we find a Rust extension in the Marketplace?.
• We should explore installing this extension https://marketplace.visualstudio.com/items?itemName=swellaby.vscode-rust-test-adapter as it seems like an easy way to debug tests.

As these are a lot of small things, maybe we should group them in a tracking issue that links to them together with the issues upstream, and add only this parent tracking issue to our Github Projects.

[Findeton]

@edulix I've created the tracking issue in SDB.