What this PR does / why we need it:

We currently always fetch the project list from the root path by default, even if the UI is served from a non-root path via PUBLIC_URL.

It seems reasonable to assume that the project list would be served from the same path as the UI by default, so change the default project list URL to include the basename from PUBLIC_URL. This way you don't need to specify a custom projectListPromise for this base case, as shown by the changes in ui/src/index.tsx.

Breaking change

The PUBLIC_URL environment variable is now taken into account by default when fetching the project list. This is a breaking change only if all these points apply:

1. You're using Feast UI as a module
2. You're serving the UI files from a non-root path via the PUBLIC_URL environment variable
3. You're serving the project list from the root path
4. You're not passing the feastUIConfigs.projectListPromise prop to the FeastUI component

In this case, you need to explicitly fetch the project list from the root path via the feastUIConfigs.projectListPromise prop:

 const root = createRoot(document.getElementById("root")!);
 root.render(
   <React.StrictMode>
-    <FeastUI />
+    <FeastUI
+      feastUIConfigs={{
+        projectListPromise: fetch("/projects-list.json", {
+            headers: {
+              "Content-Type": "application/json",
+            },
+          }).then((res) => res.json())
+      }}
+    />
   </React.StrictMode>
 );

Which issue(s) this PR fixes:

No existing issue, this came up in #5004 (comment):

(And now looking at that, we could use basename in defaultProjectListPromise too, so you wouldn't always need to provide a custom projectListPromise just for this, but maybe that's for another pull request. 😄)

Misc

I made this pull request because this new behavior would better match my expectations as a developer than the previous one, and would require less code if e.g. the PUBLIC_URL changes in different environments for a project. But I may well have missed something because I don't know the situations in which people use PUBLIC_URL. So feel free to dismiss this if it's not worth the hassle. 🙂