feat: MUD API support

[k1rill-fedoseev]

Docs PR - blockscout/docs#277

Checklist for your Pull Request (PR)

• If I added new functionality, I added tests covering it.
• If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.
• I checked whether I should update the docs and did so by submitting a PR to https://github.com/blockscout/docs
• If I added/changed/removed ENV var, I submitted a PR to https://github.com/blockscout/docs to update the list of env vars at https://github.com/blockscout/docs/blob/master/for-developers/information-and-settings/env-variables.md and I updated the version to master in the Version column. Changes will be reflected in this table: https://docs.blockscout.com/for-developers/information-and-settings/env-variables.
• If I added new DB indices, I checked, that they are not redundant with PGHero or other tools.
• If I added/removed chain type, I modified the Github CI matrix and PR labels accordingly.

[vbaranov]

• If to send incorrect world id or table id or record id, every new API endpoint returns 500 HTTP error. e.g.:

Server: localhost:4000 (http)
Request: GET /api/v2/mud/worlds/incorrect_world_id/tables/0xf28338f44e2c4a2d4cf772140bdc89a45673dfe5/records/count
** (exit) an exception was raised:
    ** (FunctionClauseError) no function clause matching in BlockScoutWeb.API.V2.FallbackController.call/2
        (block_scout_web 6.5.0) lib/block_scout_web/controllers/api/v2/fallback_controller.ex:37: BlockScoutWeb.API.V2.FallbackController.call(%Plug.Conn{adapter: {Plug.Cowboy.Conn, :...}, assigns: %{}, body_params: %{}, cookies: %{}, halted: false, host: "localhost", method: "GET", owner: #PID<0.22407.0>, params: %{"table_id" => "0xf28338f44e2c4a2d4cf772140bdc89a45673dfe5", "world" => "incorrect_world_id"}, path_info: ["v2", "mud", "worlds", "incorrect_world_id", "tables", "0xf28338f44e2c4a2d4cf772140bdc89a45673dfe5", "records", "count"], path_params: %{"table_id" => "0xf28338f44e2c4a2d4cf772140bdc89a45673dfe5", "world" => "incorrect_world_id"}, port: 4000, private: %{BlockScoutWeb.ApiRouter => {["API"]..

Could we handle wrong provided params?

• I noticed, that response /api/v2/mud/worlds/0xca62fcc0758f5461da77d3c47bc4a9e519366528/tables/0x6f74776f726c6400000000000000000046756e6374696f6e5369676e61747572/records/0x0ba51f4900000000000000000000000000000000000000000000000000000000 contains:

...
        "table_full_name": "ot.world.FunctionSignatur",
        "table_name": "FunctionSignatur",
...

Is this typo in table name (missing "e" at the end) or artefact of decoding?

[vbaranov]

Does it make sense also adding sorting by log_index as well?

[k1rill-fedoseev]

As far as I understand, since the default sorting for MUD is [asc: :key_bytes], whenever we are sorting by key0 / key1, key_bytes will still stay in the ORDER BY clause, so the order will be deterministic.

There was also a question of whether we should add a sorting by [desc: block_number, desc: log_index] as well. I have decided to not implement it for now as it requires an additional index in the MUD database and should be probably added by the lattice team.

[vbaranov]

Lets define "\u0000" as module attribute

[k1rill-fedoseev]

Replaced it with <<0>> to be stay sync with rest of the codebase.

[k1rill-fedoseev]

There is no typo in ot.world.FunctionSignatur, it's a limitation of a MUD framework. Since the total table ID is 32 bytes, its sub-parts have hard length limits: 2 bytes for table type, 14 bytes for namespace, 16 bytes for table name. So some namespace and table names have to be truncated unfortunately.

[vbaranov]

Let's add new MUD-related envs into /docker-compose/envs/common-blockscout.env and PR to docs page with envs.