Support additional API Versioning strategies

[justin-tay]

Description

Adds support for the following API Versioning strategies

• Path
• Header
• Parameters
• Media Type Profile

This can be customized by implementing and registering a com.yahoo.elide.core.request.route.RouteResolver.

The default in Elide Spring Boot is now using the Path strategy instead of using the ApiVersion header. The Path strategy is the only one that is supported when integrating with Springdoc as the other strategies are difficult to document with OpenAPI.

This can be configured back to the previous defaults using application.yaml.

The default in Elide Standalone now accepts all the strategies and can be configured to previous defaults with the getRouteResolver method.

Modifications were also made to ensure the entities for different API versions can be in the same OpenAPI document. This also adds GroupedOpenApi support for Springdoc.

The following API changes were also made

• The com.yahoo.elide.core.security.RequestScope interface has changed to be able to return a Route. This replaces the getApiVersion(), getRequestHeaderByName(), getBaseUrlEndPoint() and getQueryParams() methods.
• The JSON-API relevant fields in com.yahoo.elide.core.RequestScope have been moved to com.yahoo.elide.jsonapi.JsonApiRequestScope.
• The JSON-API processing logic in com.yahoo.elide.Elide have been moved to com.yahoo.elide.jsonapi.JsonApi.
• The ElideSettingsBuilder has been changed to be more consistent with the other Lombok builders and to allow easier customization over the defaults instead of replacing it.

Motivation and Context

Previously only the Header API Versioning strategy was supported it wasn't easy to customize to add other strategies. The other changes are also to make Elide easier to customize.

How Has This Been Tested?

Added the relevant unit and integration tests. Have also tested this against the example apps.

License

I confirm that this contribution is made under an Apache 2.0 license and that I have the authority necessary to make this contribution on behalf of its copyright owner.

[aklish]

Love the PR. Small comment that will help me move these along faster is to break this up into different PRs. Maybe name changes can be done in one PR - separate from the meat. Name changes are a lot of lines, but quick and easy to review. I know this isn't always possible - but the sweet spot would be 500 lines or less in one go.

Also helpful is some signal when the PR is ready for review.

[justin-tay]

Love the PR. Small comment that will help me move these along faster is to break this up into different PRs. Maybe name changes can be done in one PR - separate from the meat. Name changes are a lot of lines, but quick and easy to review. I know this isn't always possible - but the sweet spot would be 500 lines or less in one go.

Also helpful is some signal when the PR is ready for review.

Noted your comments. I will try to break this PR up.

Thanks for all the hard work doing the reviews, merges and releases. It's much appreciated.

It's a little tricky to break this PR up. I think what I will do is convert this to a draft and create the smaller change PRs and when those get merged I will rebase this one until it is small enough.

[aklish]

I think this could be simpler with a regex.

[justin-tay]

While I didn't profile it, since this essentially called for every request, I thought that doing string operations might be faster than a regex.

[aklish]

Ok. The logic looks correct to me.

[aklish]

Suggestion for how to start breaking this up. Let's separate the Resolvers & validators and their tests as a starting PR. I realize nothing will call these resolvers, but I think if we can break this into chunks, we can get this reviewed and merged.

[aklish]

After the resolvers, maybe we can separate just the ElideSettingsBuilder changes as its own PR.

[justin-tay]

These changes have been merged in separate PRs.