data-management-api: validate query parameters

[ndr-brt]

What this PR changes/adds

Adds validation on query params before building the QuerySpec object.
To do that introduces a QuerySpecDto object that is valued through the @BeanParam annotation.

Why it does that

To better validate input on query call

Further notes

• Bump some dependencies

Linked Issue(s)

Closes #1235

Checklist

• added appropriate tests?
• performed checkstyle check locally?
• added/updated copyright headers?
• documented public classes/methods?
• added/updated relevant documentation?
• added relevant details to the changelog? (skip with label no-changelog)
• formatted title correctly? (take a look at the CONTRIBUTING and styleguide for details)

[paullatzelsperger]

This needs to have the @JsonIgnore annotation, otherwise Jackson will look for a valid field. A serialization test would have surfaced that. Mind adding one?

For example:

    @Test
    void verifySerialization() throws JsonProcessingException {

        var dto = QuerySpecDto.Builder.newInstance()
                .filter("some filter")
                .limit(10)
                .offset(2)
                .build();

        var mapper = new ObjectMapper();
        var json = mapper.writeValueAsString(dto);

        assertThat(json).isNotNull();
        var d = mapper.readValue(json, QuerySpecDto.class);
        assertThat(d).usingRecursiveComparison().isEqualTo(dto);
    }

[ndr-brt]

This class is never serialized to/deserialized from json, so it's not needed

[paullatzelsperger]

I haven't checked, but what about tests (integration, e2e)?

[ndr-brt]

tests are working just fine without touching them, I just add a "failing query" test for every controller

[paullatzelsperger]

sure, that'll work, but as far as I'm aware @algattik has plans to generate a java API client from our own OpenAPI spec and use that in tests. If that is the case we'd indeed have to serialize the QuerySpecDto.

[ndr-brt]

@paullatzelsperger I'm not sure about that, however I would leave this for that issue, if it's needed it will be done

[paullatzelsperger]

ok, fine for me.

[bscholtes1A]

Hi @ndr-brt
looks good!
Not related to this PR but we have in the backlog the input validation for Data Plane API #1163
The different is that the public API of the DPF takes random path/query params and body (they are forwarded to the backend data source).

Will the approach you introduce in this PR also applicable in the context of the Data Plane API?

[ndr-brt]

hey @bscholtes1A I don't think the same approach could be used there because, as you said, there isn't the possibility to know what parameters will be passed upfront.
Probably the simplest (and good enough?) validation there could be just a size limit for body and query