Iox-#2128 Support segment name configuration

[gpalmer-latai]

Pre-Review Checklist for the PR Author

1. Add a second reviewer for complex new features or larger refactorings
2. Code follows the coding style of CONTRIBUTING.md
3. Tests follow the best practice for testing
4. Changelog updated in the unreleased section including API breaking changes
5. Branch follows the naming format (iox-123-this-is-a-branch)
6. Commits messages are according to this guideline
   • Commit messages have the issue ID (iox-#123 commit text)
   • Commit author matches Eclipse Contributor Agreement (and ECA is signed)
7. Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
8. Relevant issues are linked
9. Add sensible notes for the reviewer
10. All checks have passed (except task-list-completed)
11. All touched (C/C++) source code files from iceoryx_hoofs are added to ./clang-tidy-diff-scans.txt
12. Assign PR to reviewer

Notes for Reviewer

One of several Pull Requests implementing the design described in https://github.com/eclipse-iceoryx/iceoryx/pull/2140/files?short_path=b929aa6#diff-b929aa69d30dd941515f8c2d7e162051113bede6fa3b4a06e1aa4693279ce3b8 and resolving issue eclipse-iceoryx#2128

Checklist for the PR Reviewer

• Commits are properly organized and messages are according to the guideline
• Code according to our coding style and naming conventions
• Unit tests have been written for new behavior
• Public API changes are documented via doxygen
• Copyright owner are updated in the changed files
• All touched (C/C++) source code files from iceoryx_hoofs have been added to ./clang-tidy-diff-scans.txt
• PR title describes the changes

Post-review Checklist for the PR Author

1. All open points are addressed and tracked via issues

References

• Closes TBD

[anolley-latai]

Suggested change

	// Copyright (c) 2023 by Latitude AI. All rights reserved.
	// Copyright (c) 2024 by Latitude AI. All rights reserved.

[anolley-latai]

Do we care if the name gets truncated? I'm wondering about cases where we have two or more segments with names that are too long, but whose prefixes match up to the point where they are truncated, like:

a_really_long_name_for_a_segment_that_is_idential_up_to_here
a_really_long_name_for_a_segment_that_is_idential_up_to_there

But maybe the truncation of both just yields: a_really_long_name_for_a_segment_that_is_idential_up_to_ and we have a weird name conflict which is not apparent by reading the config file.

[gpalmer-latai]

Yeah this is kind of an annoying point. FWIW in the next PR I replace the "multiple writers" error with a "duplicate segment name" error which causes the program to crash. You get an informative error message. As you will see it could probably be handled more close to the config parsing better but I'm trying to balance locality of changes vs taking on larger refactoring.

[gpalmer-latai]

I presume there are also going to be weird errors if the writer/reader groups are too large.

I might poke around a bit at adding a config-time check for the length of these.

[anolley-latai]

Yeah makes sense and I don't expect we'll encounter the string size limit as a problem all that often anyway.