Embedded transactions cannot be filtered by address (instead of signerPublicKey)

[Vektrat]

Giving the address as alternative to signerPublicKey does not yield results for aggregate transactions even though it should (assuming meta.addresses has involved addresses in it, just like in regular transactions). However, aggregate transactions lack this meta field, leaving them with just signerPublicKey.

We considered asking core to add meta.addresses to aggregate transactions, however, since this is a specific case, and since signerPublicKey is a core transaction field (unlike for example, targetAddress which is specific to certain types of transaction), we can bypass this issue at REST side with an extra condition.

The drawback other than making the query a little more complex, is that converting from address to publicKey requires an extra trip to the database, the advantage is that since this is the signer we are talking about, we can be sure that the publicKey will be available. Note that clients cannot provide both signerPublicKey and address, avoiding extra trouble from param management.

Important note: this is not 100% perfect with this approach, because the issue goes a bit further than this, since we are only considering the signerPublicKey, and for different aggregate types we would still be skipping transactions with fields such as recipientAddress, targetAddress, etc... we could start adding OR to the conditions with all the extra address possibilities, but still seems hacky and error prone, so more discussion is probably still due

[Vektrat]

picked up conversation here: https://nemgroup-workspace.slack.com/archives/C015AEQ9ZL2/p1602246423414300