Reduce json input on API to the fields we store

[manuelwedler]

While working on Vyper's storage_layout_overrides, I came across this problem of the API: We currently take the standard json input from the user and pass it directly to the compiler as it is. This means a currently unsupported field like interfaces of Vyper (#2750) is given to the compiler and leading to the expected compilation output. However, we don't store this field in the database and this makes it impossible to recompile the contract later from the data we have in the database.

To address this, I propose to reduce the user given json input to the fields we actually support when passing it to the compiler. This enforces a failed verification for unknown fields which modify compiler behavior but we don't store in the database. The reasoning is we cannot control when a compiler decides to add a new top level json input field that we have to add support for.

[kuzdogan]

How would you like to ensure consistency? A shared validation function across the API and the StorageService?

The stripping down at the storage step happens implicitly, because we assign JSON input fields to database fields explicitly. So I'm wondering how we can make sure this step and the user input validation can be consistent. Maybe something like a JSON schema check?

[manuelwedler]

At the moment, it is actually explicitly stripped down to storage_layout_overrides in lib-sourcify and server. Maybe we should simply pass all json input fields (apart from language, sources and settings) to the additional_input column and let the database constraint throw?

Still, some validation middleware on the API would be good for better UX. So, I think we will end up with defining the supported additional input fields in the db constraint and in the API layer.