draft feat: roles for api keys

[dave-gray101]

Roles

This was prepared as a quick option in case we want a demo.
Currently working on an improved version using casbin for permanent version - will replace this PR when finished.

---

initial version of a role system for api keys, allowing users to be granted more finely grained access to specific parts of localai

Some notes:

• adds a new configuration file that is shipped by default named roles.json - exists to give sane combinations of endpoints easy names, though technically this can be skipped.

• changes how api_keys are interpreted. Now it's a map of api key ==> slice of endpoints
  whenever api_keys.json is evaluated (including at the initial program load) we shake out the endpoint slice - reducing roles to raw endpoints and deduplicating

• the old format for api_keys.json still works... and is interpreted as if all keys are ui user

• a fake api key of "_" represents the set of endpoints that should be authorized for unauthenticated users. Currently this also expands the access of all authenticated users - so "_" serves as the single default set of allowed to all endpoints. Let me know if anyone can think of a reason to have the complication of two distinct lists

I'd appreciate help testing every possible use case... as well as ideas for ways to improve roles.json such as different groupings or things I've missed

Docs will need to be updated to match this, but I want to do that in a separate PR for organizational reasons.

[netlify]

✅ Deploy Preview for localai canceled.

Name	Link
🔨 Latest commit	6b91703
🔍 Latest deploy log	https://app.netlify.com/sites/localai/deploys/664426ba4ddcec0008112af8

[mudler]

I really think this adds a complexity layer that should be out of LocalAI - ideally there are reverse proxy that can work with this. What is the use-case at hand here?

I'm also ok to merge it - but it should at least use another argument to not break current API_KEY usage - let's keep it as is and map it to have access to all the API endpoints.

[mudler]

I think we shouldn't break user's configuration by changing API_KEYS - let's have another argument for api keys with roles or support both notations in API_KEYS

[cryptk]

I agree with Mudler. I don't like the idea of breaking existing API_KEYS for this.