fix: AtomicI64, AtomicU64 for build mipsel processor

[TGLuong]

Fixes #
Design discussion issue (if applicable) #

Changes

• Use portable-atomic for mipsel processor. Because when build for mipsel architecture, it don't have AtomicI64, AtomicU64 in std.

Please provide a brief description of the changes here.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.1%. Comparing base (69e7e89) to head (f000612).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2301   +/-   ##
=====================================
  Coverage   79.1%   79.1%           
=====================================
  Files        119     119           
  Lines      22555   22555           
=====================================
  Hits       17842   17842           
  Misses      4713    4713           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[TGLuong]

ref: #2054

[cijothomas]

are these the only place this SDK uses Atomics?

[brunobrolesi]

could you add this for xtensa arch too? I'm trying to use this sdk on ESP32 and getting this error:

error[E0432]: unresolved imports `std::sync::atomic::AtomicI64`, `std::sync::atomic::AtomicU64`

[cijothomas]

@TGLuong Hi do you have bandwidth to continue working on this?

[cijothomas]

@brunobrolesi Would you be willing to take over and continue this work? We can give @TGLuong few days to respond, and then you can pick this up, if you are okay!

[brunobrolesi]

@cijothomas Sorry for the delay, I did get around to implementing the fix locally, but I ran into more problems that will prevent me from continuing development for the time being. For the xtensa architecture, these problems exist in the hyper and socket 2 libs and prevent the use of otel with exporters that use http.

hyperium/hyper#3684
rust-lang/socket2#516

Note: Adding target_arch = “xtensa” to the same places where @TGLuong had added the validations allowed me to use the stdout exporter

[cijothomas]

@cijothomas Sorry for the delay, I did get around to implementing the fix locally, but I ran into more problems that will prevent me from continuing development for the time being. For the xtensa architecture, these problems exist in the hyper and socket 2 libs and prevent the use of otel with exporters that use http.

hyperium/hyper#3684 rust-lang/socket2#516

Note: Adding target_arch = “xtensa” to the same places where @TGLuong had added the validations allowed me to use the stdout exporter

Thanks for checking. Looks like these architectures could use a formal, production ready stdout exporter - #2602