Add test cases and fix inlineDatum fetching for the Cardano CLI Backend

[nielstron]

No description provided.

[codecov-commenter]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (58e0cb2) 83.17% compared to head (9110b9f) 83.42%.

Files	Patch %	Lines
pycardano/plutus.py	71.42%	2 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #303      +/-   ##
==========================================
+ Coverage   83.17%   83.42%   +0.24%     
==========================================
  Files          28       28              
  Lines        3412     3415       +3     
  Branches      835      836       +1     
==========================================
+ Hits         2838     2849      +11     
+ Misses        424      416       -8     
  Partials      150      150              

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

[nielstron]

This is now a bit weird. We can have both 1 (int) and RawPlutusData(data=1) representing smart contract integer data. I guess the original idea of RawPlutusData was to wrap CBorTags somehow semantically...

So one way to fix this would be to have RawPlutusData.from_dict return the raw data if the resulting type is not CBorTag. But then x.to_dict() might fail. I think I would prefer to have a semantic type like RawPlutusData wrapping everything that is supposed to be onchain data, so that it always supports to_cbor, to_dict, to_json etc. Alternatively there could be to_json(x: Datum) functions. Currently it is just not really clear how to convert between the different representations of onchain data the cleanest possible way.

[nielstron]

This change is also necessary to allow parsing the following transaction from cbor:

84a700818258206d2174d3956d8eb2b3e1e198e817ccf1332a599d5d7320400bfd820490d706be000d818258202ce7134a6d76394cdb834418174d87aa278cf504293599a987790d64bed2278200018182583900069ec509ce2afc79debee151b7b6edd1087dbb02fe6d92956a798222d81f6bcfdd338a3d22a37366f299384983694482936e70efdd1875441a02dc6c001082583900069ec509ce2afc79debee151b7b6edd1087dbb02fe6d92956a798222d81f6bcfdd338a3d22a37366f299384983694482936e70efdd1875441a006acfc0111a002dc6c0021a001e84800b582046990f906d057f5a033a78a258425b1e10c06bc887bf017728ea324ff3c4843ca400818258205f3472d363d383974924e72861727de79a1e7b07e05b39ab8b35d1e08b1f04c658401d61275cc60d3d71a5c3fb8e4136ac9b90c769f4e683780cf1de668ab8f097bf939d8ddf4d4714534faf58a5694057932fa9cb6c98abd5dc3be4f4c1afa4210806814746010000222601048119077a0581840000187b820a0af4f6

[cffls]

LGTM, thanks!