Support presigned image URLs in markdown

[eladlachmi]

Closes #6412

This isn't a bug per se since we decided not to support pre-signed URLs when this was implemented.
This PR adds this support.

Two things to note:

1. react-markdown doesn't support async plugins (see here). To get around this, I've replaced react-markdown with @beeswax/react-markdown-async. This is not the official package and isn't heavily used. I've reviewed the code to ensure nothing fishy is going on. I've also locked down the package version. Since npm package versions are immutable, this shouldn't be a major security risk. However, this isn't ideal and we should plan to follow this up with a move from react-markdown to react-remark
2. In the issue, you mentioned image URLs using API endpoints directly, e.g., /api/v1/repositories/first1/refs/main/objects?path=images%2Fcreate-lakefs-branch.png. This is not the intended use case. The supported URLs for replacement are lakefs:// URIs and relative paths. Using API endpoints as image URLs in the quickstart is a mistake. We should discourage this practice because it essentially embeds specific API endpoints, path parameters, and querystring parameters in MD files. This is exactly the thing that the lakefs:// URI scheme is supposed to abstract away.

[github-actions]

E2E Test Results - DynamoDB Local - Local Block Adapter

[N-o-Z]

Maybe I'm missing something,
Anywhere presign is hardcoded to false we need to pass to configuration parameters for presign no?

[Isan-Rivkin]

@eladlachmi Code looks good, thank you!
I was wondering about the package you added on npm it leads to an incorrect Github repository with 12.3K starts, that's odd!
I wanted to inspect it on Github, it's probably me missing something. Could you kindly point me to the public source code?

[eladlachmi]

Could you kindly point me to the public source code?

@Isan-Rivkin This version of the package doesn't have its own GitHub repo. It's a fork of the original package, but the forked repo isn't public for whatever reason. The creator of this package didn't update the README.md or the package.json (except for the package name), so the links are to the original repo. You can view the code on the code tab of the package page.

[Isan-Rivkin]

@eladlachmi The code in the PR - no comments, LGTM.

But, this package raises a big Red Flag to me due to few reasons:

• First, there's lack of visibility to the source code in a more public "judging" manner, such a Github.
• Second, The download usage is basically 0 since 34 weekly downloads is reflecting automated scans.
• Third, I looked at the code on NPM tab as suggested but really felt like it's not the right context to do a security review to a package. Looking at Snyk I can see a low healthy score.

This means that even if the package good, we will lower our overall security score of lakeFS project.
Especially since it's in the critical path (access to users data) I am very hesitant.
Can we use an alternative?

[eladlachmi]

@Isan-Rivkin I've refactored the code to move from react-markdown to rehype-react + remark-rehype, which is the recommended way to go according to the unified maintainers. I've also upgraded all plugins (incl. our custom plugin) to the latest version for compatibility with the latest version of rehype-react and remark-rehype.
You'll notice I changed CustomMarkdownRenderer.tsx to CustomMarkdownRenderer.jsx. I tried to type this correctly for the better part of the last hour, and I'll admit, I gave up 😔 Since it has a simpler return value now, the type validation isn't as critical, so I'll take the L.

[Isan-Rivkin]

LGTM, Looks wonderful very nice improvement!