Support protobuf 3.22 or upper

[owent]

Fixes #2095

Changes

Protobuf depends on abseil-cpp 20230125 from v22/v4.22.

It removed stringpiece.h, google::protobuf::Base64Escape and use absl::Base64Escape for alternative.

We have encountered multiple problems related to the usage of CMake packages in the past (#705 #1359). As a solution, I have added a patch script cmake/patch-imported-config.cmake that allows users to use prebuilt packages with different CONFIG settings when building otel-cpp.

BTW: gRPC v1.55.0 also depend the new protobuf and abseil-cpp, so I also test the new gRPC version in the new CI job.

• Support protobuf 3.22 or upper
• Add a CI job (cmake_modern_protobuf_grpc_test) to test building with new protobuf and gRPC.
• Patch imported target in cmake CONFIG packages to enable users to use prebuilt packages with different CONFIG settings.
• Remove --experimental_allow_proto3_optional when running protoc when we use protobuf 3.16 or upper. (It's not experimental any more)

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

Merging #2163 (fdff03d) into main (b7fd057) will decrease coverage by 0.10%.
The diff coverage is 82.40%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2163      +/-   ##
==========================================
- Coverage   87.62%   87.52%   -0.10%     
==========================================
  Files         198      199       +1     
  Lines        5856     5981     +125     
==========================================
+ Hits         5131     5234     +103     
- Misses        725      747      +22     

Files Changed	Coverage Δ
sdk/src/common/base64.cc	82.40% <82.40%> (ø)

[ThomsonTan]

There seems some syntax error for modern protobuf without abseil. Is this expected, or modern protobuf does require abseil?

https://github.com/open-telemetry/opentelemetry-cpp/actions/runs/5753570940/job/15599220018?pr=2163

[lalitb]

should these methods be moved to https://github.com/open-telemetry/opentelemetry-cpp/blob/main/api/include/opentelemetry/common/string_util.h ?

[owent]

There are a lot of codes here, do you think it's better to move it into sdk?

[lalitb]

Yeah good point, not required. We can move it later if need to share with other components. Thanks.

[owent]

base64 algorithm is moved into sdk now.

[lalitb]

Really sorry if my comment above was not clear. I did realize that this will bloat the sdk, and we should move it only when we need to share it with other components.

[owent]

There seems some syntax error for modern protobuf without abseil. Is this expected, or modern protobuf does require abseil?

https://github.com/open-telemetry/opentelemetry-cpp/actions/runs/5753570940/job/15599220018?pr=2163

I just tested this CI job and find protobuf can not work when both external and internal abseil-cpp exists.Because they share the same header paths and namespace and will have conflicts with each other.
Maybe we can move headers os internal abseil-cpp into another path, do not inline namespace otel_v1 and replace all usage absl:: in otel-cpp by a macro (OTABSL_NAMESPACE for example) and then we can define OTABSL_NAMESPACE to absl when we have HAVE_ABSEIL, or define it to absl::otel_v1. By this way we can keep ABI compatibility and use the internal and external abseil at the same time without break the ABI.

@lalitb This PR is ready to be reviewed again and thanks,

[lalitb]

Maybe we can move headers os internal abseil-cpp into another path, do not inline namespace otel_v1 and replace all usage absl:: in otel-cpp by a macro (OTABSL_NAMESPACE for example) and then we can define OTABSL_NAMESPACE to absl when we have HAVE_ABSEIL, or define it to absl::otel_v1. By this way we can keep ABI compatibility and use the internal and external abseil at the same time without break the ABI.

Thanks for your analysis @owent. This would be helpful.

[owent]

@lalitb @marcalff Could you please review this PR again? I have moved base64 codes into sdk and there are a lot of changes, so I removed od-to-merge label. I think we can add it back after the new changes are reviewed.

[lalitb]

@lalitb @marcalff Could you please review this PR again? I have moved base64 codes into sdk and there are a lot of changes, so I removed od-to-merge label. I think we can add it back after the new changes are reviewed.

@owent - Seems you missed my comment here - #2163 (comment) . Actually, I didn't ask for moving base64 from otlp to sdk in my subsequent comments. But if you want, we can keep it in sdk for now, and have a separate PR to move back to otlp. Rest of the PR looks good.

[owent]

@lalitb @marcalff Could you please review this PR again? I have moved base64 codes into sdk and there are a lot of changes, so I removed od-to-merge label. I think we can add it back after the new changes are reviewed.

@owent - Seems you missed my comment here - #2163 (comment) . Actually, I didn't ask for moving base64 from otlp to sdk in my subsequent comments. But if you want, we can keep it in sdk for now, and have a separate PR to move back to otlp. Rest of the PR looks good.

Thanks. I can move it back to otlp exporter later in another PR.