feat(jans-cedarling): cedarling logging design, retrieval, and shipping

Description

Development target issue Logging requirements here https://github.com/JanssenProject/jans/wiki/Cedarling-Nativity-Plan#cedarling-logger

Ensure that latest requirements are captured, and rust design will meet those requirements.

log schema

document full log schema at https://github.com/JanssenProject/jans/wiki/Cedarling-Nativity-Plan#log-schema

`cedar::PartialResponse` for errors

Should this be used to provide more information on requests that were not authorized?

`pop_logs` design

Say a binding calls pop_logs. The binding implementation in Rust calls that on the Cedarling instance. Logs are removed from the Cedarling instance, by the pop_logs implementation.

The log entries are then converted by the binding code to some other representation. But something goes wrong, and the conversion code throws an error. The logs are now lost. This would not be acceptable.

Implementation Details

`description` field in `reason` - yes

1) The reason field is currently the policy_id only. Is it worthwhile to have a description field alongside the reason field?

2) What would it take to add the description field? policy_id comes from a cedar::Policy instance, but description is only in cedarling::common::policy_store::PolicyStore.

Prepare

[x] Read contribution guidelines
[x] Read license information

Identified code changes

[ ] update LogEntry instantiation in crate::authz::Authz::authorize(..) to have description from cedarling::PolicyStore https://github.com/JanssenProject/jans/issues/10276
[ ] task 2 etc

Test cases and code coverage

[ ] Write unit test to cover added/changed code
[ ] Update integration tests to cover added/changed code

Document the changes

[ ] task for updating user guides if needed
[ ] task for updating installation and configuration guides if needed
[ ] task for updating developer documentation if needed
[ ] task for updating technical documentation if needed

JanssenProject / jans