Create core packages for auth and api communication related logic

[f1ames]

• @monokle/parser - existing resources parsing logic already duplicated in multiple places (Desktop, Cloud, CLI), see #4. In progress - #478.
• @monokle/synchroniser - logic related to Authentication and API communication. Done in #476.

---

We started working on integration between multiple Monokle projects. The central point is Monokle Cloud and all other tools (Desktop, VSC extension, CLI, Admission Controller, etc) will communicate and integrate with it. This means there is common logic which will be the same for all the tools and should be extracted as core package preferably.

This logic includes:

• Authentication
  • Device flow and token based
• API communication
  • Fetching data from Cloud API (user info, policies, etc)
• Common logic related to the above, e.g.:
  • Checking if folder is a git repo
  • Resources parsing for validation (which uses core library already)
  • Storage - how and where fetched data is stored (e.g. policies configuration)

For me it seems that it could be good to have two separate packages:

API

For:

• Authentication
  • Device flow and token based
• API communication
  • Fetching data from Cloud API (user info, policies, etc)

Based on what we already have in separate projects:

• Device flow - https://github.com/kubeshop/vscode-monokle/blob/503a71f6e93e84381d79d0f2e7cce86f8d1ea79f/src/utils/device-flow.ts
• API communication - https://github.com/kubeshop/vscode-monokle/blob/f1ames/feat/device-flow/src/utils/api.ts
• Policies configuration fetching - https://github.com/kubeshop/vscode-monokle/blob/503a71f6e93e84381d79d0f2e7cce86f8d1ea79f/src/utils/policy-puller.ts

Utils

For:

• Common logic related to the above, e.g.:
  • Checking if folder is a git repo
  • Resources parsing for validation (which uses core library already)
  • Storage - how and where fetched data is stored (e.g. policies configuration)

Based on what we already have in separate projects:

• Git related logic - https://github.com/kubeshop/vscode-monokle/blob/503a71f6e93e84381d79d0f2e7cce86f8d1ea79f/src/utils/git.ts
• Resources parsing
  • https://github.com/kubeshop/monokle-cli/blob/2840aaf7fa039a5221fabfb9c8289d3d27784f42/src/utils/resource.ts
  • https://github.com/kubeshop/monokle-cli/blob/2840aaf7fa039a5221fabfb9c8289d3d27784f42/src/utils/extract.ts
• Storage related - https://github.com/kubeshop/vscode-monokle/blob/503a71f6e93e84381d79d0f2e7cce86f8d1ea79f/src/utils/store.ts

Remarks

Just some things I encountered recently which seems worth mentioning:

• For consistent, cross-os storage we can use env-paths (as much popular alternative to xdg-app-paths).
• Everything which should be shared between different Monokle tools, should be stored in shared/common paths.
• Policy for given local repo may be stored as provider-owner-name.policy.yaml. This way the name can be easily deducted only base don local files. Also when you move folder location the file name won't change (in opposition to e.g. generating file name based on root folder location).
• Consider Monokle Cloud project context vs local repo context. We can have ability to prefetch policies (and other data) for all projects defined in Monokle Cloud, but then local folders will need additional context (to know to which project they belong). This is related (and a different approach) than previous point.
• It might be reasonable to implement some caching for API layer (using anything like https://www.npmjs.com/package/lru-cache or https://www.npmjs.com/package/node-cache).
• Consider push scenario (instead of pull), when policy gets updated in the Cloud and may need to be send to all "active tools". This may not be needed when we don't use caching and prefetching.

[f1ames]

To reiterate, we would have two separate packages:

• @monokle/parser - existing resources parsing logic already duplicated in multiple places (Desktop, Cloud, CLI), see #4.
• @monokle/synchroniser - logic related to Authentication and API communication.