NH-64716 Fix lambda extension setup and OboeAPI call

[tammy-baylis-swi]

Fixes lambda extension linking by adding lambda env var checks to CustomBuildExt.run() in setup.py. The Make target wrapper stays the same. The symlinks (liboboe.so and liboboe.so.0) are created to point to the appropriate, already-downloaded c-lib .so at time of APM Python installation, including when run on local. This makes it easier to test lambda behaviour on local as long as the two LAMBDA env vars are set in the test environment. This stops SSL issue and incorrect sampling decisions I was seeing during testing.

I also simplified setup.py by removing CustomBuildExtLambda and its uses, and moving what it did into CustomBuildExt. Lambda layer builds work by using CustomBuildExt now.

Fixes OboeAPI call to use the same args as when calling Context to get sampling decision.

Tests pass at 63ab599, then I reverted the c-lib 14 stg commit.

[cheempz]

LGTM, nice simplification of setup.py @tammy-baylis-swi! The failed test run seems like a blip?

[tammy-baylis-swi]

Thanks @cheempz !

The failed test run seems like a blip?

The tests are failing because they're run with c-lib 13 instead of 14 from staging. Is it worth it to add catches/switches in the tests so that e.g. parts are skipped if c-lib < 14? Or allow fails until 14 is released?

[cheempz]

Thanks @cheempz !

The failed test run seems like a blip?

The tests are failing because they're run with c-lib 13 instead of 14 from staging. Is it worth it to add catches/switches in the tests so that e.g. parts are skipped if c-lib < 14? Or allow fails until 14 is released?

Ah, I think we're close enough to liboboe 14 release that it's not worth changing the tests.