Expose mappings of requirements, provides and modules to modules

[hikinggrass]

EVerest modules and even individual interface implementations can have mappings
assigned to them. These mappings are inspired by the OCPP 3-tier model.

Modules can access the mapping information in the following ways depending on which specific information is required, all of these return an optional Mapping struct
If the mapping of a requirement is of interest it can be accessed via a get_mapping() function of a requirments:
r_name_of_the_requirement->get_mapping()

If the mapping of an interface implementation is of interest it can also be accessed via a get_mapping() function: p_name_of_an_implementation->get_mapping()

If the mapping of the current module is of interest it can be accessed via the module info:
this->info.mapping

Mapping information is also available in error reporting via "error.origin.mapping":

const auto error_handler = [this](const Everest::error::Error& error) {
    const auto evse_id = error.origin.mapping.has_value() ? error.origin.mapping.value().evse : 0;
};

[Pietfried]

lgtm. Linting is currently failing

Tested with EVerest/everest-core#872

[a-w50]

I would like to request some documentation in the commit message about what has been implemented here.

[a-w50]

Does this default representation make any sense?

[hikinggrass]

The feature (at the moment at least) is inspired by the 3-tier mappings from OCPP. So if you have no explicit mapping it's assumed that the module maps to the whole charging station, getting more specific by a mapping to an evse and/or connector

[a-w50]

I see. Still I'm unsure, whether the string Mapping(charging station) on a text console will help users to understand what is meant.

[hikinggrass]

I would like to request some documentation in the commit message about what has been implemented here.

Added to the PR description which will be in the squashed commit message, it's also already available in the documentation: https://everest.github.io/nightly/general/05_existing_modules.html#tier-module-mappings (the code snippets didn't render, should be fixed soon)

[a-w50]

See the comments, please address function signatures and if possible remove the mapping from the Requirement struct.

[a-w50]

I really doubt the value of these comments, you get exactly the same information if you look at the function signature.

[a-w50]

This pattern happens quite often. It is usually better to use the iterator instead of doing the lookup twice:

const auto mapping_it = ...find(impl_id);
if (mapping_id == std::end(...)) {
  return default;
}
return *mapping_it;

[hikinggrass]

I guess something like this would be quite readable:

const auto& mappings = module_tier_mappings.value();
const auto mapping_it = mappings.implementations.find(impl_id);
if (mapping_it == mappings.implementations.end()) {
    return mappings.module;
}
const auto& [key, mapping] = (*mapping_it);
return mapping;

The alternative doesn't quite feel as readable:

...
return (*mapping_it).second;

Or what do you think?

[a-w50]

I'm uncertain with that name: RequirementInitialization sounds more like the result of the initialization of a requirement than a mapping from each requirement name to its initializer.

[hikinggrass]

I'm open for suggestions 😄 that was the best I could come up with at the time 😅

[a-w50]

This is a bit tricky. We implicitly rely on the fact, that requirements are sorted within the map according to their index. This should be guaranteed, but still is not obvious to the reader. Having the requirement without it's index, but instead pointing at a vector of Fulfillments would probably make the code even simpler.