docker runner: invalid ELF header for native_engine.so

Seen while trying to recompile Pants after a Rust change when running ./pants test src/python/pants/util: with _environment="docker" set on the python_tests target in that directory:

E   ImportError: /pants-sandbox/pants-sandbox-AFre0p/src/python/pants/engine/internals/native_engine.so: invalid ELF header

This is on a M1 macOS laptop.

% find . -name  native_engine.so
./.pants.d/tmprsfi_13f/src/python/pants/engine/internals/native_engine.so
./.pants.d/tmpj8lq_edq/src/python/pants/engine/internals/native_engine.so
./.pants.d/tmpsezhu2ug/src/python/pants/engine/internals/native_engine.so
./src/python/pants/engine/internals/native_engine.so
% file .pants.d/tmprsfi_13f/src/python/pants/engine/internals/native_engine.so
.pants.d/tmprsfi_13f/src/python/pants/engine/internals/native_engine.so: Mach-O 64-bit dynamically linked shared library x86_64
% file .pants.d/tmpj8lq_edq/src/python/pants/engine/internals/native_engine.so
.pants.d/tmpj8lq_edq/src/python/pants/engine/internals/native_engine.so: Mach-O 64-bit dynamically linked shared library x86_64
% file .pants.d/tmpsezhu2ug/src/python/pants/engine/internals/native_engine.so
.pants.d/tmpsezhu2ug/src/python/pants/engine/internals/native_engine.so: Mach-O 64-bit dynamically linked shared library x86_64
% file ./src/python/pants/engine/internals/native_engine.so
./src/python/pants/engine/internals/native_engine.so: Mach-O 64-bit dynamically linked shared library arm64

cc @Eric-Arellano @stuhood

This is known. It's because it's a resource that gets copied from localhost, and it does not have platform awareness. it's why you need to use --no-python-infer-conftests and only run on strutil_test.py so that native_engine.so doesn't end up in transitive closure

I don't know what the solution would be, other than "platform aware resource targets" or something. Or conditional dependencies.

Because Pants is bootstrapped in a platform dependent way (the rust code is always built on localhost), we will not be able to cross-build our integration tests across platforms anytime soon. I don't think that this is something that we should tackle.

As @Eric-Arellano said: a conftests.py file tries to pull in the engine, which causes even tests which shouldn't have a dependency on the engine to do so. We should fix that much, to allow us to actually dogfood more directly, but allowing integration tests which consume the engine in general to run in docker (or remotely cross-platform: i.e. from macOS to Linux) shouldn't be a goal.