Return encoded extrinsics without padding

[Kailai-Wang]

Context

It should fix the ExtrinsicNotFound error during enclave registration.

With the padded version (post-padded with spaces 0x20) the extrinsic submission would succeed since the decoding goes through even with postpositioned (unused) bytes. However, the substrate-api-client wouldn't find the hash with the prolonged extrinsic that we pass in.

This is also the reason why CI of #2281 failed

fixes #2168
fixes P-151

Related: scs/substrate-api-client#624

[Kailai-Wang]

Reported upstream too: integritee-network/worker#1505

[kziemianek]

@Kailai-Wang does it fix #2168 ?

[Kailai-Wang]

@Kailai-Wang does it fix #2168 ?

It should.

However, (I was about to say to you) the registration process needs to be reviewed after this one and #2281 get merged: #1133

[linear]

P-151 Worker always fails to recognize itself as primary validateer

After a startup the worker registers itself in teerex's enclave registry and tries to determine whether he's a primary validateer (the first to be registered) or not but from my experience it looks like it always says it's not.

I've checked the campaign instances logs and it seems the problem existed there too.

[2023-09-27T21:26:23Z ERROR litentry_worker] ExtrinsicFailed ExtrinsicNotFound
[<] Extrinsic got finalized. Hash: None

In short, the implementation could not determine the block at which extrinsic was finalized so it fallbacks to current block. Then based on current block it check if any registered enclave existed before. The answer is yes, thus it pretends as it's not the primary while in fact it is.

if we_are_primary_validateer {
println!("[+] We are the primary validateer");
} else {
println!("[+] We are NOT the primary validateer");
}

Upstream ticket: scs/substrate-api-client#624

[BillyWooo]

Thank you for the explanation. I think it's good to go.