Add a more flexible sampling strategy data model

[garrettlish]

Which problem is this PR solving?

• Request more fine-grained control for remote sampling open-telemetry/opentelemetry-go-contrib#6127

Description of the changes

• Add a more flexible sampling strategy data model, it enables support for more fine-grained control, such as adjusting sampling probabilities based on specific tag key-value pairs (see sampling.proto).
• For instance, in a real-world scenario, we might want to enforce sampling for a particular user session by customizing sampling probabilities based on specific tag key-value pairs.

How was this change tested?

• Tested in the upcoming PR.

[yurishkuro]

This feels too simplistic to me. Compare with open-telemetry/oteps#250

[garrettlish]

This feels too simplistic to me. Compare with open-telemetry/oteps#250

Good idea. How about introducing an "any" or "conjunction" option, along with adding a dimension matching strategy, similar to the changes made in this commit - 171bccd? Any thoughts, please advise!

[yurishkuro]

I would recommend starting with some use cases and showing a yaml-equivalent of the config for those, then we can translate it to the IDL. I think your proposal is still too rigid. For example, here's the DLS that Gemini recommends:

message SamplingRule {
  // Logical expression combining conditions
  LogicalExpression expression = 1;

  // Sampling strategy
  oneof sampling_strategy {
    FixedRateSampling fixed_rate_sampling = 2;
    ProbabilisticSampling probabilistic_sampling = 3;
    // Add other sampling strategies as needed
  }
}

message LogicalExpression {
  oneof expression {
    Condition condition = 1;
    AndExpression and_expression = 2;
    OrExpression or_expression = 3;
    NotExpression not_expression = 4;
  }
}

message AndExpression {
  repeated LogicalExpression expressions = 1;
}

message OrExpression {
  repeated LogicalExpression expressions = 1;
}

message NotExpression {
  LogicalExpression expression = 1;
}

example rule

message SamplingRule {
  expression {
    and_expression {
      expressions {
        condition {
          attribute: "http.status_code"
          operator: GREATER_THAN
          int_value: 500
        }
      }
      expressions {
        condition {
          attribute: "service.name"
          operator: EQUALS
          string_value: "my_service"
        }
      }
    }
  }
  fixed_rate_sampling {
    rate: 0.5
  }
}

The challenge when dealing with expressions and boolean logic is in validating that the rules in a strategy are disjoint, as otherwise the stratas are going to overlap and proper stratified sampling probabilities cannot be determined (although we probably can deal with that by assuming a priority order of the rules where earlier rule wins, in which case even if two rules overlap in the search space prioritizing one of them will effectively make them disjoint).