Change Object to be a module package

[lxfind]

Previously, an Object can be either a Move object, or a Move module.
Each module has an internal address (because Move expects it). In Diem, such address is simply where the module is published to, and multiple modules can be published to the same address.
However in FastX, since each module has a different address, even modules from the same package will have different addresses. This makes it extremely inconvenient to program with dependencies, because when you have dependencies to modules from the same package, you have to use different addresses to refer them. For instance, FastX::ObjectBasics has a different address than FastX::Transfer, which has a different address than FastX::Coin, and etc.

This PR changes the Object (in the modules case) to be a package, which is a collection of modules that are published together and belong to the same address. To facilitate fast lookup, it is in the form of a map from module name to the underline serialized module.

To summarize the list of changes made by this PR:

1. The Data enum now has Package(MovePackage) instead of Module(Vec<u8>), which is defined as BTreeMap<String, Vec<u8>>. When fetching the ID of the Package, it picks the ID of the first module in it, as all modules share the same address in the same package.
2. A Move call order now need to also pass the module name along with the package object. @oxade for the client
3. generate_module_ids in adapter is changed to generate_package_info_map. It goes over all modules, group them by address to generate a list of packages, each package has a new id.
4. All the hardcoded addresses from different modules in the fastx framework can be removed.
5. Also had some issues with genesis deadlocking. Changed the access to genesis so that no one can lock it from outside (and hence no deadlock).

[gdanezis]

Do we have all modules in a package in the same fastx object, or do we have an index object for the package, pointing to other object containing the modules?

[lxfind]

Do we have all modules in a package in the same fastx object, or do we have an index object for the package, pointing to other object containing the modules?

The current design is to have all modules in the same fastx object. Having an index object would have the benefit of avoiding gigantic objects, seems doable to me and is a good idea.

[lxfind]

Do we have all modules in a package in the same fastx object, or do we have an index object for the package, pointing to other object containing the modules?

The current design is to have all modules in the same fastx object. Having an index object would have the benefit of avoiding gigantic objects, seems doable to me and is a good idea.

It does complicate a few things when it comes to address resolution. They should show the same abstraction to the client, so I would probably go with this first, and think about the indexing.

[sblackshear]

Great stuff!

[gdanezis]

Do we have all modules in a package in the same fastx object, or do we have an index object for the package, pointing to other object containing the modules?

The current design is to have all modules in the same fastx object. Having an index object would have the benefit of avoiding gigantic objects, seems doable to me and is a good idea.

Actually, big immutable objects are not so much of an issue, since we can aggressively cache them if they ever become an issue.

[lxfind]

All tests pass. Ready for review.
Also updated the PR summary to reflect all changes.

[oxade]

Thanks for acting on this quickly @lxfind
Will scope out the publishing from client once this is in.