Implement loader config object, allow programatic layer management.

[aarongreig]

No description provided.

[aarongreig]

this could do with some dedicated unit testing but I'm not really sure where, would feel out of place in the CTS since no adapter code will ever get called

[aarongreig]

This is a rock-and-a-hard-place type situation. There is already an XPTI env var that you need to set to enable the tracing used by this layer (actually there are several) - adding this new env var is our rock (detracts from user experience, seems generally redundant).
So the obvious thing would be to treat the XPTI one as our layer-enabling env var instead of adding the new one - but if we do that the API mechanism becomes redundant. Enabling the XPTI variable is always needed for the layer to work - you'd need to set it even if you wanted to enable your layers via api. This is our hard place, this solution makes the API redundant, and might lead to users making unnecessary API calls. At best it would be weird to document.
There is also a third, un-named, unpleasant location: we could just not report this tracing layer through the api mechanism and leave it as a kind of power-user option. This would preserve the current behaviour for existing users without being potentially misleading by reporting its existence through the loader config mechanism. That kind of sucks though because we have this functionality so we should encourage people to use it. It would also feel weird to have a layer that's fundamentally inconsistent with the layer mechanism we're trying to set up.

[pbalcer]

I had the same dilemma. I imagine most users will leverage this layer indirectly through tools like urtrace or just sycl, so the ergonomics of this are not that important. It's already complicated and requires at least some understanding of the XPTI framework.
So I'm fine with adding the new env variable, provided it's well documented.

[aarongreig]

Cool, added some documentation of the new env var mechanism and all the layers in INTRO.rst

[veselypeta]

this could do with some dedicated unit testing but I'm not really sure where, would feel out of place in the CTS since no adapter code will ever get called

There are dedicated loader tests under test/loader which would seem reasonable?

[pbalcer]

this could do with some dedicated unit testing but I'm not really sure where, would feel out of place in the CTS since no adapter code will ever get called

There are dedicated loader tests under test/loader which would seem reasonable?

Yup. I'd recommend just creating a new folder in that location for the config. These tests are less structured than the CTS ones because of the larger variety of test scenarios (e.g., launching the same process multiple times with different environment variables, with expecting predefined output), so just do whatever you think makes the most sense, either normal gtest scenarios or tests that rely on the match mechanism (like most of the existing layer tests).

[aarongreig]

cool, will add something in there

[aarongreig]

Added a CTS style unit test suite in test/loader/loader_config/ (and it immediately caught a bug!)

[kbenzie]

Couple minor comments