chore: Revise trigger message to include IP address [CHI-3828]

[gpaoloni]

Description

This PR:

• Lifts ip and contact identifier into Redux session state.
• Makes use of the above properties to include in the trigger message, matching the behavior of the older webchat.

Checklist

• Corresponding issue has been opened
• New tests added
• Feature flags added
• Strings are localized
• Tested for chat contacts
• Tested for call contacts

Other Related Issues

None

Verification steps

AFTER YOU MERGE

1. Cut a release tag using the Github workflow. Wait for it to complete and notify in the #aselo-deploys Slack channel.
2. Comment on the ticket with the release tag version AND any additional instructions required to configure an environment to test the changes.
3. Only then move the ticket into the QA column in JIRA

You are responsible for ensuring the above steps are completed. If you move a ticket into QA without advising what version to test, the QA team will assume the latest tag has the changes. If it does not, the following confusion is on you! :-P

[gpaoloni]

@copilot Take a look at the failing unit tests and fix them in a separate PR (to be merged against this one).

• The changes in the code should not be reverted, only fix the tests according to the new behavior.
• Where possible, add new test cases.

[Copilot]

@gpaoloni I've opened a new pull request, #4279, to work on those changes. Once the pull request is ready, I'll request review from you.

[gpaoloni]

@copilot In a new PR, add unit tests for the changes in this PR:

• aselo-webchat-react-app/src/components/MessagingCanvasPhase.tsx: test that the "auto first message" uses contactIdentifier, ipAddress and DEFAULT_CUSTOMER_DEFAULT_NAME according to which is present.
• Add tests to the session reducer for the new actions ACTION_SET_IP_ADDRESS and ACTION_SET_CONTACT_IDENTIFIER.

[Copilot]

@gpaoloni I've opened a new pull request, #4282, to work on those changes. Once the pull request is ready, I'll request review from you.

[stephenhand]

Sorry, missed this. We should always use interpolated string keys for dynamic data like this rather than hardcoding the interpolation. People may not always want the contact identifier to come at the end of their message

Also fallbacks like DEFAULT_AUTO_FIRST_MESSAGE are pointless, localizeKey returns the unmodified key if no translation can be found anywhere in the hierarchy, not a falsey value