ai: add models webhook url param

[gioelecerati]

What does this pull request do? Explain your changes. (required)

In order to avoid restarting orchestrators whenever we change the runners list we'd like to have a dynamic way of setting up the -aiModels. Similarly to [-orchWebhookUrl](https://github.com/livepeer/go-livepeer/blob/master/doc/orchwebhook.md?plain=1#L4) that can be used for providing dynamic list or orchestrators on the broadcaster side.

Specific updates (required)

• Add aiModelsWebhookUrl param, accepting a string which can be either a webhook url or a file path
• Webhook gets called every 1 minute, updating the model configs
• Webhook.GetConfigs() returns the most recent config
• Added tests for both url and file updates

How did you test each of these updates (required)

unit tests

Does this pull request close any open issues?

Checklist:

• Read the contribution guide
• make runs successfully
• All tests in ./test.sh pass
• README and other documentation updated
• Pending changelog updated

[mjh1]

Looking good, just a couple of small points 👍

[mjh1]

I guess we don't need this field for now as it's not used right?

[gioelecerati]

Isn't the point of this to fetch updated model configs? I added it to be used where needed doing updatedModels = ModelsWebhook.GetConfigs() - but maybe @pwilczynskiclearcode knows better where this is needed to be used

[pwilczynskiclearcode]

It's assigned in here... and must live for the entire orchestrator lifetime and not be garbage collected or stopped.
I think it's needed.

[mjh1]

Gotcha yep, it'll be integrated in a further PR

[pwilczynskiclearcode]

@gioelecerati This entire loop needs to be run each time there are some changes to the ModelsWebhook.configs

[pwilczynskiclearcode]

@leszko Do you think this PR feature makes sense in context of remote worker, realtime AI video and future pricing policy plan

[leszko]

@leszko Do you think this PR feature makes sense in context of remote worker, realtime AI video and future pricing policy plan

@gioelecerati @thomshutt @mjh1 My thinking is that we still need this PR, but with the current setup is not the top priority. As per the latest discussion in Discord, we won't use neither External Container nor Remote Worker for Phase 1 of Realtime Video (Dec 12th deadline). So, we'll deploy a separate Orchestartor in each TensorDock machine. That means that restarting an Orchestartor is slightly less of a problem, because we'll have another Orchestrators deployed in different TensorDock machines.

Still with Realtime Video, restarting Orchestrator is an issue, because it means a downtime for livestream, but that's a separate conversation.

Long story short, I think that if it's not too much effort, then let's just take it to the finish line. However, if there are some other tasks, I think it's ok to park it for now and revisit in Dec/Jan.