Fix EscrowFinish fulfillment and condition parsing

[nkramer44]

Fixes #513

As seen in transaction 138543329687544CDAFCD3AB0DCBFE9C4F8E710397747BA7155F19426F493C8D, sometimes EscrowFinish transactions can show up in validated ledger transaction sets with an invalid fulfillment or condition. We added a fulfillmentRawValue and conditionRawValue, and normalization functions to try to make fulfillment() equivalent to fulfillmentRawValue and condition() equivalent to conditionRawValue in #483. However, we missed a special case where the fulfillment or condition could be well formed in the first 32 bytes, but contain extra bytes afterward (in the case of 138543329687544CDAFCD3AB0DCBFE9C4F8E710397747BA7155F19426F493C8D, the fulfillment is duplicated), which causes an exception to be thrown by the normalization function.

This PR fixes this issue by checking that the parsed fulfillment or condition is equivalent to the fulfillment/condition raw value. If it is not equivalent, we will not set fulfillment or condition. If it is, we will.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.66%. Comparing base (eabbafe) to head (6ba6c93).

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #512      +/-   ##
============================================
+ Coverage     91.65%   91.66%   +0.01%     
- Complexity     1774     1776       +2     
============================================
  Files           365      365              
  Lines          4948     4956       +8     
  Branches        408      410       +2     
============================================
+ Hits           4535     4543       +8     
  Misses          280      280              
  Partials        133      133              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.