Adjust the FindContent JSON-RPC call to also retrieve data over uTP

[kdeme]

Currently it was implied, due to the ConnectionId result, that the returned values are these of the CONTENT protocol call and that the uTP transfer was not done all or not awaited for. It is however more interesting to have a call that also does the data transfer over uTP.

Here the call gets adjusted to do the transfer over uTP, but the result still allows for returning ENRs when the data is not available, and to indicate whether a uTP transfer was used or not.

Looks like this in openrpc playground:

edit: new picture of how it looks after the additions of https://github.com/ethereum/portal-network-specs/pull/206/commits/1a462d57479feab46b4362dab04ea8d7a85e2186 and https://github.com/ethereum/portal-network-specs/pull/206/commits/e120d3a285c281cd4ee10e5a2d4774590fe6cfa2

[kdeme]

The response that is accepted according to this schema is for example:

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "content": "0x1234...",
    "utpTransfer": false
  }
}

or

{
  "jsonrpc": "2.0",
  "id": "1",
  "result": {
    "enrs": [
      "enr:-abc...",
      "enr:-def..."
    ]
  }
}

commit https://github.com/ethereum/portal-network-specs/commit/1a462d57479feab46b4362dab04ea8d7a85e2186 wraps the ENRs in an additional object with enrs key, which is more alike to what it was before. However, this commit could be reverted to directly provide the json array, if that would be preferred.