mock: replace objx.Map with our own mock.TestData type to drop objx

[dolmen]

Description

To drop dependency on module objx (see #1752) I propose to replace objx.Map with an internal implementation that exposes a similar (subset) API to objx.Map that is just enough for the few users of Mock.TestData.

Proposed solution

My solution with our own mock.TestData and mock.TestDataValue types that exposes the subset of objx.Map methods used in the wild.

1. Merge mock: isolate objx-dependent code in their own source files #1757.
2. Add types TestData and TestDataValue.
3. Replace use of objx.Map with mock.TestData in the signature of Mock.TestData().

package mock

import "reflect"

// TestData replaces [github.com/stretchr/objx.Map].
type TestData map[string]interface{}

type reflectValue = reflect.Value

// TestDataValue replaces [github.com/stretchr/objx.Value] and exposes the same methods as [reflect.Value].
type TestDataValue struct {
    reflectValue
}

// Set replaces [github.com/stretchr/objx.Map.Set].
func (td TestData) Set(selector string, v interface{}) {
    td[selector] = v
}

// Get replaces [github.com/stretchr/objx.Map.Get].
func (td TestData) Get(selector string) *TestDataValue {
    v, ok := td[selector]
    if !ok {
         return nil
    }
    return &TestDataValue{reflectValue: reflect.ValueOf(&v).Elem()}
}

// MustInter replaces [github.com/stretchr/objx.Value.MustInter].
func (v *TestDataValue) MustInter() interface{} {
    if v == nil {
        return nil
    }
    return v.reflectValue.Interface()
}


func (m *Mock) TestData() objx.Map {
        if m.testData == nil {
                m.testData = make(TestData)
        }

        return m.testData
}

Use case

#1752

[ccoVeille]

I'm fine with this.

It would be an acceptable breaking changes, but a breaking change anyway

Can we make it retro compatible with an interface maybe?

[dolmen]

Can we make it retro compatible with an interface maybe?

Impossible.

[dolmen]

Uses of TestData() found by Gemini

• github.com/moby/moby (Docker): Search results indicate that Moby uses a variation of this pattern. In some parts of the codebase, they have historically referenced mock.TestData or implemented a similar custom structure to reduce dependencies on objx.Map.
• aduu.dev/utils/dash/dmock: This package appears at the top of the "Imported By" list. It is a utility wrapper around testify/mock that potentially exposes or utilizes the TestData field for dashboard-related mock state.
• github.com/test-go/testify/mock and github.com/hhkbp2/testify/mock: These are prominent forks of the original library that retain and sometimes extend the TestData() functionality.
• bitbucket.org/jurnal/scm: This project has dozens of subpackages (e.g., test/mockdata/repository, test/mockdata/service/acl) that import testify/mock. While many "mockdata" references in Go refer to the testdata/ directory, this specific project uses a structure that closely aligns with the TestData() method's intended use for mock state.

To investigate.