API and language/culture support

[vvdb-architecture]

Today, we are the biggest consumers of our own APIs. Tomorrow, this may change.

Concretely, this means that we cannot keep relying on clients calling our back-ends to be clients written with the Arc4u framework. This is normally not a problem since we work with http/rest or grpc. There are two instances for which interoperability is problematic:

• language support
• exception support

This issue deals with language support. A separate issue has been filed for exception support (#37)

Currently, Arc4u has its own way of propagating culture information to API calls. This is done by clients injecting a custom header called "culture" in th request, and parsing it in the back-end middleware.
See the following code for handlers:

• https://github.com/GFlisch/Arc4u/blob/master/src/Arc4u.Standard.OAuth.Msal/Token/JwtHttpHandler.cs.
• https://github.com/GFlisch/Arc4u/blob/master/src/Arc4u.Standard.OAuth2.AspNetCore.Adal/Token/JwtHttpHandler.cs

... for grpc interceptors:

• https://github.com/GFlisch/Arc4u/blob/master/src/Arc4u.Standard.gRPC/Interceptors/OAuth2/OAuth2Interceptor.cs
• https://github.com/GFlisch/Arc4u/blob/master/src/Arc4u.Standard.gRPC/Interceptors/AuthorizationInterceptor.cs

... and for middleware:

• https://github.com/GFlisch/Arc4u/blob/master/src/Arc4u.Standard.OAuth2.AspNetCore/Middleware/ClaimsPrincipalMiddleware.cs
• https://github.com/GFlisch/Arc4u/blob/master/src/Arc4u.Standard.OAuth2.AspNetCore/Middleware/OpenIdBearerInjectorMiddleware.cs

This is problematic for two reasons:

• it ignores the standard protocol for transferring culture in http (and grpc as well, since it's really http2): Content-Language.
• the culture information is only passed in the context of authentication. However, authentication and culture information are orthogonal issues: one has nothing to do with another. It is not currently possible to pass culture information to anonymous calls. This might not be a use case today, but there might be one tomorrow.

There is built-in support for Content-Language in .NET, see Content-Language HTTP header. The Arc4u framework should switch to that support. For compatibility reasons, one may decide to keep the current mechanism, but the time should be as short as possible.