Fix getting event logs by topic

[iand]

Related Issues

Fixes filecoin-project/ref-fvm#1207

Proposed Changes

Finding event logs in the historical index by topic was broken for a few separate reasons:

1. sometime between original implementation and FIP-0049 landing the indexable flag was split into 2 distinct flags - this PR adds these as constants in the types package
2. decoding the cbor encoded byte array values was added as a fix in the api but didn't find its way into the database code which was recording cbor encoded versions of the entry values
3. the query code was not accounting for zero padding of the topic byte arrays

Points 1+2 result in bad data in the database so any existing indexed events will not be retrievable by topic even after this PR is merged. They are still retrievable via other criteria. New events logged after this merge is deployed should be fine.

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
  • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[jaeaster]

Question on these fixes... I'm seeing behavior where I can query for an event and find it
if fromBlock == targetBlock == toBlock,
but not when fromBlock < targetBlock < toBlock

e.g.

await provider.getLogs({
  address: "0xa3743970690B21043c5d14A0c9418DC7bAF33A3d",
  fromBlock: 15638,
  toBlock: 15639,
  topics: []
})
=> []

await provider.getLogs({
  address: "0xa3743970690B21043c5d14A0c9418DC7bAF33A3d",
  fromBlock: 15639,
  toBlock: 15639,
  topics: []
})
=> (3) [{…}, {…}, {…}]

Does this PR fix this issue? Otherwise, I'll open another issue. I'm not sure if the cbor encoding problem applies to block numbers (probably not)