AbstractRateLimitFilter improvements

1. I suppose it makes sense to extract applyPolicy to the separate class, that would contain a list of other filters, not knowing about concrete implementations. This change will give possibility to add custom policy filters. Something like that:

    private final List<PolicyFilter> filters;
    private final MatchersByTypeIndex matchersIndex;

    @Override
    public boolean filter(HttpServletRequest request, Route route, 
                                       RateLimitProperties.Policy policy) {
        return policy.getType().isEmpty() || allFiltersApply(request, route, policy);
    }

    private boolean allFiltersApply(HttpServletRequest request, Route route, 
                                                        RateLimitProperties.Policy policy) {
        return filters
                .stream()
                .allMatch(policyFilter -> {
                    Set<String> matchers = matchersIndex.get(policyFilter.getType());
                    return policyFilter.filter(matchers, request, route);
                });
    }

1. Consider using Set instead of List for users and origins in userApply and originApply methods. Complexity of contains operation on set is O(1), on list is O(n). Usage of Set will not degrade app if big amount of matchers is added.
2. getConfiguredType can be precomputed on startup and instead of list can be saved into map<Type, Set<String>>. So for example instead of:

    private boolean urlApply(List<MatchType> types, Route route) {
        List<String> urls = getConfiguredType(types, Type.URL);

        return urls.isEmpty()
            || route == null
            || urls.stream().anyMatch(url -> route.getPath().startsWith(url));
    }

it can be done this way:

    private boolean urlApply(List<MatchType> types, Route route) {
        Set<String> urls = matchersIndex.getOrDefault(Type.URL, Collections.emptySet());

        return urls.isEmpty()
            || route == null
            || urls.stream().anyMatch(url -> route.getPath().startsWith(url));
    }

This would decrease complexity of the method.

If you are interested I would like to open PRs with described changes.

[Aloren]

1. The main reason behind that change is that AbstractRateLimitFilter knows too much. It does all policies filtering: userApply, originApply, urlApply. I propose to extract these methods to separate simple filters and to use in AbstractRateLimitFilter only compound policy filter. Instead of:

    protected List<Policy> policy(Route route, HttpServletRequest request) {
...
        return policyMap.values().stream()
            .filter(policy -> compoundPolicyFilter.filter(request, route, policy))
            .collect(Collectors.toList());
    }

whereas PolicyFilter would look like this:

@RequiredArgsConstructor
public class OriginPolicyFilter implements PolicyFilter {
    private final RateLimitUtils rateLimitUtils;

    @Override
    public boolean filter(LinkedHashSet<String> originMatchers, HttpServletRequest request, Route route) {
        return originMatchers.isEmpty()
                || originMatchers.contains(rateLimitUtils.getRemoteAddress(request));
    }

    @Override
    public RateLimitProperties.Policy.Type getType() {
        return RateLimitProperties.Policy.Type.ORIGIN;
    }
}

It is just an idea, interfaces can be different. The main point is that adding new filter will not require touching AbstractRateLimitFilter. Moreover changing default logic behind these filtering logic wight now is impossible. 2,3. these points are actually about one thing – having separate configuration index class instead of iterating on configuration each time, so changing current configuration won’t be needed.

is the empty check neccessary? is that about urls.isEmpty()? it is an existing code, i suppose that it is not needed.

[marcosbarbero]

Closing due to inactivity.