feat: add remote materialization store for Go (#203)

Author: nicklasl

openfeature-provider/go/README.md

@@ -140,6 +140,8 @@ if err != nil {
 Configure the provider behavior using environment variables:
 
 - `CONFIDENCE_RESOLVER_POLL_INTERVAL_SECONDS`: How often to poll Confidence to get updates (default: `30` seconds)
+- `CONFIDENCE_MATERIALIZATION_READ_TIMEOUT_SECONDS`: Timeout for remote materialization store read operations (default: `2` seconds)
+- `CONFIDENCE_MATERIALIZATION_WRITE_TIMEOUT_SECONDS`: Timeout for remote materialization store write operations (default: `5` seconds)
 
 ### ProviderConfig
 
@@ -153,8 +155,12 @@ The `ProviderConfig` struct contains all configuration options for the provider:
 
 - `Logger` (*slog.Logger): Custom logger for provider operations. If not provided, a default text logger is created. See [Logging](#logging) for details.
 - `TransportHooks` (TransportHooks): Custom transport hooks for advanced use cases (e.g., custom gRPC interceptors, HTTP transport wrapping, TLS configuration)
-- `MaterializationStore` (MaterializationStore): Custom storage for sticky variant assignments and materialized segments. If not provided, the provider will 
-fall back to default values for flags with rules that require materializations. See [Materialization Stores](#materialization-stores) for details.
+- `MaterializationStore` (MaterializationStore): Storage for sticky variant assignments and materialized segments. Options include:
+  - `nil` (default): Falls back to default values for flags requiring materializations
+  - `NewRemoteMaterializationStore()`: Uses remote gRPC storage (recommended for getting started)
+  - Custom implementation: Your own storage (Redis, DynamoDB, etc.) for optimal performance
+
+  See [Materialization Stores](#materialization-stores) for details.
 
 #### Advanced: Testing with Custom State Provider
 
@@ -186,6 +192,46 @@ Materialization stores provide persistent storage for sticky variant assignments
 
 ⚠️ Warning: If your flags rely on sticky assignments or materialized segments, the default SDK behaviour will prevent those rules from being applied and your evaluations will fall back to default values. For production workloads that need sticky behavior or segment lookups, implement and configure a real `MaterializationStore` (e.g., Redis, Bigtable, DynamoDB) to avoid unexpected fallbacks and ensure consistent variant assignment. ✅
 
+### Remote Materialization Store
+
+For quick setup without managing your own storage infrastructure, enable the built-in remote materialization store. This implementation stores materialization data via gRPC to the Confidence service.
+
+**When to use**:
+- You need sticky assignments or materialized segments but don't want to manage storage infrastructure
+- Quick prototyping or getting started
+- Lower-volume applications where network latency is acceptable
+
+**Trade-offs**:
+- Additional network calls during flag resolution (adds latency)
+- Lower performance compared to local storage implementations (Redis, DynamoDB, etc.)
+
+```go
+import (
+    "context"
+
+    "github.com/open-feature/go-sdk/openfeature"
+    "github.com/spotify/confidence-resolver/openfeature-provider/go/confidence"
+)
+
+func main() {
+    ctx := context.Background()
+
+    // Enable remote materialization store
+    provider, err := confidence.NewProvider(ctx, confidence.ProviderConfig{
+        ClientSecret: "your-client-secret",
+        UseRemoteMaterializationStore: true,
+    })
+    if err != nil {
+        log.Fatalf("Failed to create provider: %v", err)
+    }
+
+    openfeature.SetProviderAndWait(provider)
+    // ...
+}
+```
+
+The remote store is created automatically by the provider with the correct gRPC connection and authentication.
+
 ### Custom Implementations
 
 For improved latency and reduced network calls, you can implement your own `MaterializationStore` interface to store materialization data in your infrastructure (Redis, DynamoDB, etc.):