feat: added theme support for icons

[3em]

• Added theme support for icons
• Added ThemeProvider context to UI
• Added icons with light mode
• Fixed useThemeStore at design-system

[CLAassistant]

All committers have signed the CLA.

[netlify]

❌ Deploy Preview for harness-design failed.

Name	Link
🔨 Latest commit	617b6a5
🔍 Latest deploy log	https://app.netlify.com/sites/harness-design/deploys/67c06b8e3c15ea00083abd38

[netlify]

✅ Deploy Preview for harness-xd-review ready!

Name	Link
🔨 Latest commit	617b6a5
🔍 Latest deploy log	https://app.netlify.com/sites/harness-xd-review/deploys/67c06b8ee622b80008492eb4
😎 Deploy Preview	https://deploy-preview-975--harness-xd-review.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[abhinavrastogi-harness]

most of the images which need a light version, are not even "icons" strictly.
i think we need to discuss and come up with a better approach for handling this.

[abhinavrastogi-harness]

this is not a good/scalable way to support "light" versions of icons as it just results in proliferation by doubling almost all icons.
we can probably do something similar to how we handled it earlier: https://github.com/harness/uicore/blob/main/packages/icons/src/Icon.tsx
basically we added an inverse prop on the Icon component, which looks for a specific file name pattern for the selected icon. if it's available the inverted one is returned, if not, the default one is returned.

[3em]

@abhinavrastogi-harness Got it. So in our case, I think we should also check if there is an icon with the -light postfix, and use it; otherwise, we fallback to the default one.
But in fact, in the example, icons for inverse are added in the same way, just with a fallback. Correct?

[3em]

@abhinavrastogi-harness I have made the changes to the PR, you can review it

[knagurski]

I think we can pretty drastically cut down on this changeset by requiring that consuming apps wrap their entire app in the ThemeProvider. We can then look for the theme directly from the Icon component and not need to alter any other view or component or require the consumer pass additional props.

Regarding different SVGs for light vs dark icons, I'm not really convinced. From experience, the majority of icons should just be invertible to get the same effect without additional weight. It might be better to add a CSS invert filter when the theme is light. In some cases this won't be ideal, so we can add in selective overrides; the flow in that case would be that we get the normal icon name, check if the theme is light, if so check if there is a light version, if so use it, otherwise use the normal icon with the invert filter.

Worth noting that work is also underway to tokenise the strokes/fills etc of icons, so in the future we'll be able to set the colouring/thickness/etc of SVG icons to whatever we need it to be for the theme from tokens studio. We're not there yet so the override/invert is probably a good stopgap.