Refactor Settings and fix launch environment

[BigRoy]

Changelog Description

Refactor settings to match with feedback in #31

Additional info

This is a first pass draft, and likely does not work. Just wanted to put it up so there's visibility on that I have a first pass on this. This now works for me, with both Houdini 20 and Maya 2024.2

• Bugfix: The used settings are now from the active bundle (and use ayon_core studio settings and project settings retrieval)
• Bugfix: Launch context environment is now maintained and used (this contains Construct AYON USD environment on top launch context environment #32)
• Bugfix: Setup resolver env logic now does not 'kill' PATH on Windows by accident because it previously stacked to LD_LIBRARY_PATH and got set to PATH. It is now 'appended'toPATH`.
• Simplifies settings (and also changes the settings keys! So note that you need to reconfigure your settings)
• Improves logging for invalid server repository, it will report now no timestamp was found for that path. Which was better than the unclear error before.
• Added more docstrings to functions

A potential downside to this PR is that aside of the LakeFS instance connection it now uses no local cache - which of course can be implemented in a separate PR later.

Testing notes:

1. Clone the repository, checkout the branch (and don't forget all the git submodules, etc.)
   • Note that there's a currently a non-working git submodule set (like in develop branch) for ayon_bin_client. Use branch release_v0_1_0 instead for that submodule. Fixed with updated bin bridge client to fix broken submodule #36
2. Configure the settings using the LakeFS urls, etc. (request them with Lyon from Ynput team)
3. Launch Maya or Houdini

[iLLiCiTiT]

Code changes look good to me, needs testing.

[BigRoy]

@Lypsolon I suppose this is now in your lap - but I'll also add @antirotor as reviewer just in case.

[Lypsolon]

Basic Testing on Almalinux 9
Installed New addon and opend houdini (Resolver was loaded as expected)

Im not the biggest fan of using direct Dict[] access but if most developers like this we can keep it this way.

i would like to ask @BigRoy and @iLLiCiTiT what you think about using a data class that simply exposes the data. aka: Dataclass(settings).lakeFs_Setting_A instead of the direct dict asses.
I prefer that but that might just be bias and if most Developers Prefer it the other way around then this code Looks Good.

[BigRoy]

Dataclass(settings).lakeFs_Setting_A instead of the direct dict asses.
I prefer that but that might just be bias and if most Developers Prefer it the other way around then this code Looks Good.

I think the best we could get to is sharing the actual pydantic setting classes and somehow be able to use that frontend without much magic and code shuffling around at runtime so that an IDE is able to pick that up. Otherwise it's still a matter of maintaining the models on both client and backend site separately - which I'd prefer to avoid.

But then we'd get type hints as well! (which copying a dataclass to client manually would also do, etc.) - however I have no idea if anything like that is even feasible without code duplication.

Anyway, again - there's merit to it, but preferably this is done in a way that makes sense across all addons. So this may be worth a separate issue in a more global space and go from there.

Also, no matter what we choose - definitely a separate issue or PR.

@Lypsolon could you give the the "Approved" stamp?

[Lypsolon]

Simple Tests have been Done under Almalinux 9 and looks like it works.
the code looks good.

[iLLiCiTiT]

We could have model that is dynamically created based on server models, but only change at the end would be that I do settings.lake_fs instead of settings["lake_fs"]. Considering there might be addons that are accessing other addons settings (should not happen, but it does), then you're kinda screwed.

Sum up: I don't see any advantage to use attributes over dictionary keys. It only adds unecessary conversion step of settings to objects, that cannot be used in IDE, because it has to be created on the fly based on current server model (which IDE does not doo).