Types tidy up

Sorry, this will be a bit vague because it's kind of general sweep of what we have. In short, we could do with stronger typing for the data that we have, in order to improve code readability and also to standardise and make re-usable things like how a given byte array is serialised in json.

### Formalise tuples that are used externally to their module

```
pub fn slot_to_epoch_with_shelley_params(
slot: u64,
shelley_epoch: u64,
shelley_epoch_len: u64,
) -> (u64, u64)
```

The above result would be better as a small struct, so that it's clear at the point of use what's been returned without having to got and read the function source.

Another example are the query topics:

```
pub const DEFAULT_POOLS_QUERY_TOPIC: (&str, &str) =
("pools-state-query-topic", "cardano.query.pools");
```

Again, at the point of use, it's not obvious what the tuple strings represent.

### Formalise types for the various byte arrays we deal with

We have many instances of byte array type variables.

```
pub struct BlockInfo {
pub timestamp: u64,
pub number: u64,
pub hash: Vec,
pub slot: u64,
pub epoch: u64,
pub epoch_slot: u64,
pub issuer_vkey: Option>,
pub size: u64,
pub tx_count: u64,
pub output: Option,
pub fees: Option,
pub block_vrf: Option>,
pub op_cert: Option,
pub op_cert_counter: Option,
pub previous_block: Option>,
pub next_block: Option>,
pub confirmations: u64,
}
```

It's not always obvious what these represent, how they should be serialised, or what length of array can be expected. Formalising the types used for these has the main benefit of the type maintaining knowledge of how to serial and deserialise the bytes, and to be able validate the data too.

### Reduce/remove serialisation types

There are some types that exist solely for serialisation.

```
#[derive(Serialize)]
pub struct PoolMetadataRest {
pub pool_id: String,
pub hex: String,
pub url: String,
pub hash: String,
pub ticker: String,
pub name: String,
pub description: String,
pub homepage: String,
}
```

As can be seen by all the members being strings, half the serialisation has already been done. I guess this is kind of the same point as the previous one, but if we give formal types to the various ids and hashes, then we shouldn't have to be doing half the serialisation before handing off the json serialiser, and some of serialisation types might disappear entirely where their structure matches that of the source data. In other cases, I don't know if we can provide some kind of lightweight view type struct?

The issue names slot_to_epoch_with_shelley_params, the query topic constants, BlockInfo, and PoolMetadataRest, but no files or tests. Start by locating these definitions and inventorying related tuple, byte-array, and serialization types. Done would require an agreed, project-wide type design with standardized serialization and validation, which the issue does not yet specify.

Written by the indexing model from the issue text.