fix(crypto): deprecate events field in shielded TRC20 scan APIs

[Federico2014]

What does this PR do?

Deprecates the events field in shielded TRC20 scan API requests and removes server-side log-type filtering.

1. Marked the events field as [deprecated = true] in IvkDecryptTRC20Parameters and OvkDecryptTRC20Parameters request messages in api.proto
2. Added runtime rejection: gRPC returns INVALID_ARGUMENT, HTTP returns 400 when the deprecated events field is populated
3. Removed topicList parameter from internal method signatures in Wallet, RpcApiService, and HTTP servlet handlers (ScanShieldedTRC20NotesByIvkServlet, ScanShieldedTRC20NotesByOvkServlet)
4. All log types (Mint/Transfer/Burn) are now always inspected during a scan
5. Added gRPC test coverage for the deprecation-rejection path across Full, Solidity, and PBFT stubs

Why are these changes required?

The events field allowed callers to filter shielded TRC20 event classes by passing user-controlled log topic strings that were hashed and matched server-side. This was an unnecessary attack surface — callers should always scan all log types and filter client-side. Removing the field simplifies the API contract and eliminates potential information leakage through selective scanning.

⚠️ Breaking Changes:

• scanShieldedTRC20NotesByIvk/Ovk — the events request field is now rejected outright (INVALID_ARGUMENT on gRPC, HTTP 400). Clients still sending the field must remove it. Clients that relied on the field to limit scan scope will now receive results for all log types.

This PR has been tested by:

• Unit Tests — RpcApiServicesTest, WalletMockTest, ShieldedTRC20BuilderTest
• Build passes (./gradlew clean build)

Follow up

No consensus logic or on-chain state transitions affected.

Extra details

[waynercheung]

[SHOULD] This catch scope is broader than the deprecation path itself. It will also turn unrelated IllegalArgumentException subclasses into HTTP 400 responses, for example NumberFormatException from Long.parseLong(...) in doGet and other IllegalArgumentException cases from JsonFormat.merge(...) in doPost. That expands the behavior change beyond "reject deprecated events". Please short-circuit the deprecated-field path directly, or use a dedicated exception type so only the events rejection is mapped to 400.

Same issue also applies to the corresponding catch blocks in ScanShieldedTRC20NotesByOvkServlet.

[Federico2014]

Thanks for flagging this. On reflection, I think the broader catch scope may actually be the right behavior here — before this PR, NumberFormatException from invalid query parameters fell through to catch (Exception) which returned HTTP 200 with an error body (since Util.processError doesn't set a status code). Returning 400 for malformed client input seems more semantically correct. Would you agree, or do you still feel we should narrow the scope to the deprecation path only?

[waynercheung]

[SHOULD] The new rejection coverage is currently gRPC-only, but HTTP 400 is also part of the external contract introduced by this PR. Please add servlet-level regression tests for scanShieldedTRC20NotesByIvk/Ovk GET and POST to verify that requests with events return HTTP 400 and include the deprecation message. A small smoke test for the Solidity/PBFT HTTP wrappers would also help confirm the status code is preserved through the futureGet(...) wrapper.

[Federico2014]

@waynercheung Fixed. Added ScanShieldedTRC20NotesServletTest covering all four cases — IVK POST, IVK GET, OVK POST, OVK GET — each asserting HTTP 400 and the deprecation message in the response body.

For the Solidity/PBFT wrappers: futureGet is synchronous and simply sets a DB cursor before delegating to super.doPost/doGet, so the rejectIfEventsPresent check and the SC_BAD_REQUEST status are set before any cursor operation is reached. The behavior is identical to the main servlet, with no additional code path to verify.