[objects] authority can return object layout to client in ObjectInfoR…

[sblackshear]

…equest

More progress on interpreting object bytes inside the client.

• Modify the authority's ObjectInfoRequest to allow the client to (optionally) request the MoveStructLayout for an object in a variety of formats
• Modify the authority's ObjectInfoResponse to return the layout if requested
• Implement the appropriate traits in the authority to allow computing the layout from its local DB

Note: three approaches to this were discussed in #397 and there was a general consensus that the third one (ask clients to store packages + use this to compute a layout locally) was preferred. However, after looking into this a bit, I concluded that this will be a major change to the client, which is not great because we need to start piping out JSON objects into the client service API's ASAP to unblock Geniteam (ideally today!).

In addition to the prioritization, I think approach (3) doesn't help a client who wants to get a structured view of an object that is not owned by them. Asking such a user to download every module related that object just to look at it + go through the dance of computing a layout from these modules doesn't seem great. Thus, I think exposing a way to ask an authority for the layout is reasonable even if we also implement approach (3).

[sblackshear]

Note: this PR is passing the layout from authority to client, but still not using the layout inside the client.

For this, what I'm imagining is:

• [urgent] passing the layout from AuthorityAggregator back into the client so it can be used to serve CLI or RPC requests that want to see a JSON structured object. If someone knows this code well and/or wants to take this on, that would be great.
• [can be done later] adding a layouts: StructTag -> MoveStructLayout field to ClientStore
• [can be done later] populating this field with the layout of all the objects the client owns

Let me know if this sounds reasonable.

[oxade]

Note: this PR is passing the layout from authority to client, but still not using the layout inside the client.

For this, what I'm imagining is:

• [urgent] passing the layout from AuthorityAggregator back into the client so it can be used to serve CLI or RPC requests that want to see a JSON structured object. If someone knows this code well and/or wants to take this on, that would be great.
• [can be done later] adding a layouts: StructTag -> MoveStructLayout field to ClientStore
• [can be done later] populating this field with the layout of all the objects the client owns

Let me know if this sounds reasonable.

Still prefer just sticking to Option3 and not burdening the Authorities with UX tasks, but in any case, I can get on the urgent step so we can unblock Geniteam
Created issue here for client piece #434

[oxade]

Might be easier to review after after merge conflicts resolved

[sblackshear]

not burdening the Authorities with UX tasks

I would push back both against characterizing returning the layout as a burden and as needed only for UX.

• It's cheap and convenient for authorities to compute struct layouts. An authority already needs to do this for every object type that gets passed into a Move call
• Without the layout, a client cannot know how to interpret an object's contents (which I think goes a bit beyond UX--the system isn't useful if clients can't see how a smart contract call changed the contents of an object).

So far, we have been insulated from this because the client harcodes the layout of the one object type we do anything with: the gas object. But we can't hardcode the layouts for user-defined object types that aren't present in genesis.

[oxade]

not burdening the Authorities with UX tasks

I would push back both against characterizing returning the layout as a burden and as needed only for UX.

• It's cheap and convenient for authorities to compute struct layouts. An authority already needs to do this for every object type that gets passed into a Move call
• Without the layout, a client cannot know how to interpret an object's contents (which I think goes a bit beyond UX--the system isn't useful if clients can't see how a smart contract call changed the contents of an object).

So far, we have been insulated from this because the client harcodes the layout of the one object type we do anything with: the gas object. But we can't hardcode the layouts for user-defined object types that aren't present in genesis.

Makes sense

[sblackshear]

Thanks for the quick review!!