(otelarrowreceiver): add admission control to otlp path

[moh-osman3]

Description:
This PR helps memory issues in the standard OTLP data path by sharing the semaphore used for admission control in the arrow data path.

[jmacd]

@moh-osman3 I think it will save us and the users some work if we leave a compatibility mode in place for several releases, allowing the former arrow::admission settings to be used. I would do this by leaving copies of the two old fields in the ArrowConfig struct, with the factory defaulting both fields to zero. If during Validate() the field is set to non-zero, then it overrides the new field.

I think this can be done with

var _ component.ConfigValidator = (*Config)(nil)

func (cfg *Config) Validate() error {
    if err := cfg.GRPC.Validate(); err != nil {
        return err
    }
    if err := cfg.Arrow.Validate(); err != nil {
        return err
    }
    if cfg.Arrow.MemoryLimitMiB != 0 {
        cfg.Admission.MemoryLimitMiB = cfg.Arrow.MemoryLimitMiB
    }
    // ... same for waiters
    return nil
}

[moh-osman3]

Hmm test failing because

Vulnerability #1: GO-2024-3106
    Stack exhaustion in Decoder.Decode in encoding/gob
  More info: https://pkg.go.dev/vuln/GO-2024-3106
  Standard library
    Found in: encoding/gob@go1.22.6
    Fixed in: encoding/gob@go1.22.7
    Example traces found:
Error:       #1: receiver.go:158:45: googlecloudmonitoringreceiver.monitoringReceiver.initializeClient calls google.FindDefaultCredentials, which eventually calls gob.Decoder.Decode

Your code is affected by 1 vulnerability from the Go standard library.
This scan also found 0 vulnerabilities in packages you import and 2
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.

[crobert-1]

Hmm test failing because

It looks like this CVE was just published today, it will need resolved in its own PR. It's failing on main, and unrelated to this change. 👍

[jmacd]

I'm not sure what's going on with prometheus-compliance-tests / prometheus-compliance-tests but it's blocking these three otherwise ready-to-merge OTel-Arrow PRs:

#35021
#35225
#34742

[crobert-1]

I'm not sure what's going on with prometheus-compliance-tests / prometheus-compliance-tests

It's frequency of #35119, unrelated to this change. 👍

[lquerel]

Two minor comments otherwise LGTM.