enhancement: build for wasi

[public-rant]

What does this PR change? What problem does it solve?

Build for wasi

Setting the stage for being able to run (a subset of) restic in the browser

Was the change previously discussed in an issue or on the forum?

I can't see any discussion of Web Assembly on GitHub

Checklist

• I have read the contribution guidelines.
• I have enabled maintainer edits.
• I have added tests for all code changes.
• I have added documentation for relevant changes (in the manual).
• There's a new file in changelog/unreleased/ that describes the changes for our users (see template).
• I have run gofmt on the code in all commits.
• All commit messages are formatted in the same style as the other commits in the repo.
• I'm done! This pull request is ready for review.

[MichaelEischer]

What is the use case for running restic in the browser? There's no filesystem to read from?

In addition, please remove the additional CI tasks and use our standard cross-building setup https://github.com/restic/restic/blob/master/.github/workflows/tests.yml#L200 .

[public-rant]

#832

[MichaelEischer]

Embedding restic into a website is fundamentally different from adding an HTTP API (well actually REST API) to restic.

[public-rant]

I see your point.

I hadn't expected to draw any attention to this (draft) PR before it was ready, and I apologise for wasting resources by running workflows when it was not necessary.

I suppose my goal can be restated as "enabling restic to be interacted with via a REST API", regardless of whether or not it is embedded in a website.

For example, the functions in this file could allow one to create /snapshots/new and /snapshots/find endpoints. And if those features work correctly, and the project could be built in a WASM environment, then one could send data from web filesystem API to a restic repository by using the restic.NewSnapshot and restic.FindFilteredSnapshots directly rather then hitting endpoints which call those functions.

As I worked on this, I realised it doesn't need to be part of the main restic repo, as I can achieve my goal by exposing internal features of restic using go mod edit -replace and pointing to a local copy of restic which I keep as a submodule.

I defer to your expertise as to whether or not there is any value in exposing restic's internals to the outside world.

[MichaelEischer]

There are currently no plans on our side to expose the internals of restic as that would create an API that should remain mostly stable. Keeping the CLI backwards compatible is already enough work.