chore: merge probe-engine into probe-cli (#201)

This is how I did it:

1. `git clone https://github.com/ooni/probe-engine internal/engine`

2. ```
(cd internal/engine && git describe --tags)
v0.23.0
```

3. `nvim go.mod` (merging `go.mod` with `internal/engine/go.mod`

4. `rm -rf internal/.git internal/engine/go.{mod,sum}`

5. `git add internal/engine`

6. `find . -type f -name \*.go -exec sed -i 's@/ooni/probe-engine@/ooni/probe-cli/v3/internal/engine@g' {} \;`

7. `go build ./...` (passes)

8. `go test -race ./...` (temporary failure on RiseupVPN)

9. `go mod tidy`

10. this commit message

Once this piece of work is done, we can build a new version of `ooniprobe` that
is using `internal/engine` directly. We need to do more work to ensure all the
other functionality in `probe-engine` (e.g. making mobile packages) are still WAI.

Part of https://github.com/ooni/probe/issues/1335

internal/engine/atomicx/README.md

@@ -0,0 +1,3 @@
+# Package github.com/ooni/probe-engine/atomicx
+
+Atomic int64/float64 that works also on 32 bit platforms.

internal/engine/atomicx/atomicx.go

@@ -0,0 +1,68 @@
+// Package atomicx contains atomic int64/float64 that work also on 32 bit
+// platforms. The main reason for rolling out this package is to avoid potential
+// crashes when using 32 bit devices where we are atomically accessing a 64 bit
+// variable that is not aligned. The solution to this issue is rather crude: use
+// a normal variable and protect it using a normal mutex. While this could be
+// disappointing in general, it seems fine to be done in our context where
+// we mainly use atomic semantics for counting.
+package atomicx
+
+import (
+	"sync"
+)
+
+// Int64 is an int64 with atomic semantics.
+type Int64 struct {
+	mu sync.Mutex
+	v  int64
+}
+
+// NewInt64 creates a new int64 with atomic semantics.
+func NewInt64() *Int64 {
+	return new(Int64)
+}
+
+// Add behaves like atomic.AddInt64
+func (i64 *Int64) Add(delta int64) (newvalue int64) {
+	i64.mu.Lock()
+	i64.v += delta
+	newvalue = i64.v
+	i64.mu.Unlock()
+	return
+}
+
+// Load behaves like atomic.LoadInt64
+func (i64 *Int64) Load() (v int64) {
+	i64.mu.Lock()
+	v = i64.v
+	i64.mu.Unlock()
+	return
+}
+
+// Float64 is an float64 with atomic semantics.
+type Float64 struct {
+	mu sync.Mutex
+	v  float64
+}
+
+// NewFloat64 creates a new float64 with atomic semantics.
+func NewFloat64() *Float64 {
+	return new(Float64)
+}
+
+// Add behaves like AtomicInt64.Add but for float64
+func (f64 *Float64) Add(delta float64) (newvalue float64) {
+	f64.mu.Lock()
+	f64.v += delta
+	newvalue = f64.v
+	f64.mu.Unlock()
+	return
+}
+
+// Load behaves like LoadInt64.Load buf for float64
+func (f64 *Float64) Load() (v float64) {
+	f64.mu.Lock()
+	v = f64.v
+	f64.mu.Unlock()
+	return
+}

internal/engine/atomicx/atomicx_test.go

@@ -0,0 +1,50 @@
+package atomicx_test
+
+import (
+	"testing"
+	"time"
+
+	"github.com/ooni/probe-cli/v3/internal/engine/atomicx"
+)
+
+func TestInt64(t *testing.T) {
+	// TODO(bassosimone): how to write tests with race conditions
+	// and be confident that they're WAI? Here I hope this test is
+	// run with `-race` and I'm doing something that AFAICT will
+	// be flagged as race if we were not be using mutexes.
+	v := atomicx.NewInt64()
+	go func() {
+		v.Add(17)
+	}()
+	go func() {
+		v.Add(14)
+	}()
+	time.Sleep(1 * time.Second)
+	if v.Add(3) != 34 {
+		t.Fatal("unexpected result")
+	}
+	if v.Load() != 34 {
+		t.Fatal("unexpected result")
+	}
+}
+
+func TestFloat64(t *testing.T) {
+	// TODO(bassosimone): how to write tests with race conditions
+	// and be confident that they're WAI? Here I hope this test is
+	// run with `-race` and I'm doing something that AFAICT will
+	// be flagged as race if we were not be using mutexes.
+	v := atomicx.NewFloat64()
+	go func() {
+		v.Add(17.0)
+	}()
+	go func() {
+		v.Add(14.0)
+	}()
+	time.Sleep(1 * time.Second)
+	if r := v.Add(3); r < 33.9 && r > 34.1 {
+		t.Fatal("unexpected result")
+	}
+	if v.Load() < 33.9 && v.Load() > 34.1 {
+		t.Fatal("unexpected result")
+	}
+}