Add smart_contract field to address object

[sabondano]

Motivation

• For GraphQL API users to be able to get a smart_contract by
  address. RPC API users could use this instead of the getabi and
  getsourcecode RPC actions.

  Example usage:

      query ($hashes: [AddressHash!]!) {
        addresses(hashes: $hashes) {
          fetched_coin_balance
          smart_contract {
            name
            compiler_version
            optimization
            contract_source_code
            abi
            address_hash
          }
        }
      }
  

Changelog

Enhancements

• Adding jason dependency. Needed for JSON scalar type.
• Adding dataloader dependency to help Absinthe efficiently load data
  in batches.
• Editing Schema by adding context callback. It adds a dataloader
  source to context.
• Adding JSON scalar type. Needed by abi field in smart_contract
  object.
• Adding smart_contract object type.
• Editing address object type to include smart_contract field.
• Adding Explorer.Chain.data/0. It creates an Ecto Dataloader source
  for Absinthe to use.

[coveralls]

Pull Request Test Coverage Report for Build 98a52940-9fb1-4744-8ede-eddb58e78e45

• 4 of 6 (66.67%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 89.113%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
apps/block_scout_web/lib/block_scout_web/schema/scalars/JSON.ex	1	2	50.0%
apps/explorer/lib/explorer/chain.ex	0	1	0.0%

Totals
Change from base Build 7472772c-0598-4edc-a74a-ec945e097ac7:	0.0%
Covered Lines:	3315
Relevant Lines:	3720

---

💛 - Coveralls

[KronicDeth]

In the PR description you say

RPC API users could use this instead of the getabi and getsourcecode RPC actions.

But I don't see a change to the RPC API docs. You should add it in there to guide users on the GraphQL API upgrade path like we discussed before.

[sabondano]

@KronicDeth yes 👍. It's on my list of things to do. My plan was to open a single PR editing the RPC API docs for all actions we currently have similar support for on the GraphQL API. I'm thinking it'll make the PR review easier and we can discuss what's the best way to do that on that separate PR. After that PR, all GraphQL API enhancements could include the necessary edits to the RPC API documentation. If that works for all, I'll proceed accordingly but let me know.