Store OCPI platforms party_id and country_id

[atschabu]

Currently the library only stores a platforms tokens, combined with the versions URL as identifier. While this is sufficient for authentication of a remote party, it isn't enough to identify them. We currently workaround this issue by storing the platforms country_code and party_id when storing TOKEN_A, though this could be handled by the library as part of the registration process, by downloading the other platforms Credentials once tokens have been exchanged.

The reason we need this information, is to identify calls made to Session endpoints, so we can filter return values based on the caller (eg: only return Sessions, that were initiated by Tokens owned by the calling eMSP). Similarly, when pushing Session objects to an eMSP, at the time of creating the Session object, all we have are the identifiers of that platform, and not its base URL.

The simplest solution would be, to keep the platformURL as identifier and add methods to the PlatformRepository interface for associating the identifiers:

    suspend fun getPlatformUrlByIdentifiers(country_code: String, party_id: String): String?
    suspend fun savePlatformIdentifiers(platformUrl: String, List<IdentifierPair>: String)

[atschabu]

oh .. and maybe also a retrieval method for the identifiers, similar to the getEndpoints method

    suspend fun getPlatformIdentifiers(platformUrl: String): List<IdentifierPair>

... though at this point I wonder if it would be easier to have a Platform domain object, containing all this info (url, versions, endpoints, identifiers) so it is expandable, and simplifies the interface by removing a few getters

[lilgallon]

I agree with you. In this PR: #23, I updated and fixed a few things in credentials module. To keep all the information exchanged by a partner, we will store its list of CredentialsRole (it includes countryCode / partyId).

Then in your implementation, you can extend PlatformRepository to add your custom methods to retrieve a Platform object from its countryCode / partyId or anything else.

As long as the ocpi-toolkit does not directly need countryCode / partyId to work, we do not need to add methods to retrieve this information in PlatformRepository. It's up to the user of the lib to implement its own method to return the right information in each OCPI endpoint.

I may miss something as I am currently only testing credentials and version module with real partners. I started working on Location module recently, that is why I found out that the lib needed to store countryCode / partyId.

I am not totally convinced about having a Platform domain object yet. Real world feedback may convice me, but for now I prefer that the user of the lib keeps freedom on their Platform definition

PS: I will rename Platform to Partner as platform is not really clear in PR #23