NEX-195: Allow the frontend to access the backend via internal url in runtime

[vermario]

This PR introduces the concept of an internal url to access drupal from the frontend.

The backend needs to be accessible by a public URL for these reasons:

1. the editors need to log into the site and do their content editing work
2. in our example, there is a flow where the user asks to register on the frontend, gets an email with the link to go to drupal and set the password, gets redirected back
3. the build of the site is done in our case by CircleCI and it's not feasible to allow access to the internal url because the circle ci agent does not have a predictable IP.

But, it would be useful for the node.js process running in next.js to access the backend also with an internal URL. In SILTA, this means that the data flows inside the same cluster, and does not involve our CDN.

One thing that we had to take into consideration was the fact that we are using next-image, and both the internal and external urls need to be allowed as source for the images.

I have added the same concept to the lando and ddev setups, because hopefully this would allow us to catch subtle bugs in case we are using the wrong internal/external url for drupal there.

Summary of the changes:

Configuration Updates:

• .circleci/config.yml: Added environment variables DRUPAL_BASE_URL_INTERNAL and DRUPAL_BASE_URL_INTERNAL_IMAGES to handle internal URLs and ensure they are used within CircleCI. [1] [2] [3]
• .ddev/config.yaml: Added DRUPAL_BASE_URL_INTERNAL and DRUPAL_BASE_URL_INTERNAL_IMAGES for local development.
• .lando.yml: Added DRUPAL_BASE_URL_INTERNAL and DRUPAL_BASE_URL_INTERNAL_IMAGES for Lando environments.
• silta/silta-next.yml: Added DRUPAL_BASE_URL_INTERNAL and DRUPAL_BASE_URL_INTERNAL_IMAGES for Silta environments.

Code Updates:

• next/next.config.mjs: Updated the image hostname handling to use both external and internal Drupal URLs, ensuring valid URLs are provided. [1] [2]
• next/src/app/api/health/route.ts: Changed the health check endpoint to use the internal Drupal URL.
• next/src/auth.ts: Updated OAuth token fetching to use the internal Drupal URL. [1] [2]
• next/src/components/formatted-text.tsx: Modified image source URLs to use the internal Drupal URL.
• next/src/env.ts: Added internal Drupal URL environment variables to the environment configuration. [1] [2]
• next/src/lib/drupal/drupal-client.ts: Updated the GraphQL client to use the internal Drupal URL.

[hkirsman]

I liked also this explanation from Slack thread:

Main issue:

If the frontend uses the fastly-protected public url for drupal, we unnecessarily generate
fastly traffic (since drupal also runs behind fastly, as for our normal procedures), and we
might incur in issues with rate limiting (since the frontend is seen as an individual "client"
doing a lot of calls, and it might be blocked,

[vermario]

I found this issue in tests:

basically the email link is generated using the internal url for drupal this way... will have to fix

[vermario]

I found this issue in tests:

basically the email link is generated using the internal url for drupal this way... will have to fix

Fixed in https://github.com/wunderio/next-drupal-starterkit/pull/289/commits/b5cfb18fd623e35686944db081291118dbe5f454