fix: correctly serialize a multsig call, then parse WrapperKeepOpaque, and WrapperOpaque

[TarikGul]

closes: #835

This PR resolves serializing a MultiSig call and correctly parsing the args with the added WrapperKeepOpaque, and WrapperOpaque types. The code is a little repetitive to keep it readable, and understandable, also parseGenericCalls is heavily leveraging recursion so best to not mess with the logic much.

I added an e2e test for the block mentioned in the issue to ensure we are tracking a WrapperKeepOpaque call.

This is via polkadot-js/api v7.6.1

[jsdw]

LGTM, not a big fan of the repetition since it is identical even at a type level but up to you :)

[TarikGul]

@jsdw I made the changes to stop the repetition, i totally agree that the solution you provided was way better.

[dvdplm]

It's a bit hard to map the code in the try…catch block to each of the three cases. What do you think about something like this:

			} else if (
				argument &&
				paramName === 'call'
			) {
				switch (argument?.toRawType()) {
					case 'Bytes':
					case 'WrapperKeepOpaque<Call>':	
						newArgs[paramName] = argument;
					case 'WrapperOpaque<Call>':
						const call = registry.createType('Call', argument.toHex());
						newArgs[paramName] = this.parseGenericCall(call, registry);
	
					default:
						// log or otherwise report error?;
				}

(Not sure I got the cases right, which is illustrating the point I guess)

[niklasad1]

I like that if that works :)

[TarikGul]

So actually each of the 3 cases are going to map out to the same output i.e.

					try {
						const call = registry.createType('Call', argument.toHex());
						newArgs[paramName] = this.parseGenericCall(call, registry);
					} catch {
						newArgs[paramName] = argument;
					}

therefore the above wont work. I filed an issue here regarding the try catch in order to potentially optimize it. For this PR i think it is out of scope as we are just extending the conditional to include WrapperKeepOpaque<Call>, and WrapperOpaque.

[TarikGul]

Merging. @dvdplm I think your comment has some merit above, and should be given some extra investigation and potential optimization. That being said, for the scope of this PR, lets just patch the bug (since the solution itself is pretty simple and doesnt change any of the core logic when parsing the generic calls). But I will follow this PR up with the issue I filed and see what we can do :)