Add endpoints for IPv4 and IPv6 only

[MathieuLamiot]

Description

Refactor of hard-coded IPs for re-use in different generation methods
Fixes #89

Documentation

User documentation

The change will automatically be cached and used in our online doc.

Technical documentation

NA

Type of change

Delete options that are not relevant.

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).

New dependencies

NA

Risks

NA

Checklists

Feature validation

• I validated all the Acceptance Criteria. If possible, provide sreenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Documentation

• I prepared the user documentation for the feature/enhancement and shared it in the PR or the GitHub issue.
• The user documentation covers new/changed entry points (endpoints, WP hooks, configuration files, ...).
• I prepared the technical documentation if needed, and shared it in the PR or the GitHub issue.

Code style

• I wrote self-explanatory code about what it does.
• I wrote comments to explain why it does it.
• I named variables and functions explicitely.
• I protected entry points against unexpected inputs.
• I did not introduce unecessary complexity.
• I listed the introduced external dependencies explicitely on the PR.
• I validated the repo-specific guidelines from CONTRIBUTING.md.

Observability

• I handled errors when needed.
•  I wrote user-facing messages that are understandable and provide actionable feedbacks.
• I prepared ways to observe the implemented system (logs, data, etc.).

Risks

•  I explicitely mentioned performance risks in the PR.
• I explicitely mentioned security risks in the PR.

[pull-request-checklist-buddy]

Pull Request & Code Review Checklists

Pull Request author's checklist

Feature validation

• I validated all the Acceptance Criteria. If possible, provide sreenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Documentation

• I prepared the user documentation for the feature/enhancement and shared it in the PR or the GitHub issue.
• The user documentation covers new/changed entry points (endpoints, WP hooks, configuration files, ...).
• I prepared the technical documentation if needed, and shared it in the PR or the GitHub issue.

Code style

• I wrote self-explanatory code about what it does.
• I wrote comments to explain why it does it.
• I named variables, functions, classes and files explicitely.
• I protected entry points against unexpected inputs.
• I did not introduce unecessary complexity.
• I listed the introduced external dependencies explicitely on the PR.
• I validated the repo-specific guidelines from CONTRIBUTING.md.

Observability

• I handled errors when needed.
• I wrote user-facing messages that are understandable and provide actionable feedbacks.
• I prepared ways to observe the implemented system (logs, data, etc.).

Risks

• I explicitely mentioned performance risks in the PR.
• I explicitely mentioned security risks in the PR.

Code Reviewer's checklist

• I checked that the CI passed.
• I understand how the code solves the issue.
• I read the provided user documentation and confirmed it is enough to cover the usage of the code.
• I read the provided technical documentation and confirmed it is enough to cover the maintenance of the code.
• I easily understand what the code does and how it does it.
• I find the naming of variables, functions, classes and files explicit.
• I find the code complexity justified.
• I find the introduced external dependencies necessary.
• I find that the repo-specific guidelines are followed.
• I cannot think of a way to break the code.
• I find that the mentioned risks are sufficiently mitigated.
• I cannot think of any other risks.