chore: Move Option and Enumerable to immutables

[fredcarle]

Relevant issue(s)

Resolves #854
Resolves #853

Description

This PR adds no new code. It's simply moving or renaming things. Mainly, the Option and Enumerable types are moved the immutables package and the UpdateEvent is moved to the events package are renamed Update.

Tasks

• I made sure the code is well commented, particularly hard-to-understand areas.
• I made sure the repository-held documentation is changed accordingly.
• I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in tools/configs/chglog/config.yml).
• I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ...

How has this been tested?

make test

Specify the platform(s) on which this was tested:

• MacOS

[AndrewSisley]

Enumerable might be leaving the defra repo entirely quite soon - not sure it is worth touching it here. This would also leave us with the immutables package containing only a doc.go and the options sub-package, which I'm not sure makes sense.

[fredcarle]

Enumerable might be leaving the defra repo entirely quite soon - not sure it is worth touching it here. This would also leave us with the immutables package containing only a doc.go and the options sub-package, which I'm not sure makes sense.

There wouldn't be an options sub-package. It stays at the root of immutables. It makes more sense to have it here than in client in my opinion.

[AndrewSisley]

There wouldn't be an options sub-package. It stays at the root of immutables. It makes more sense to have it here than in client in my opinion.

You'd prefer an immutables package with a single type, than to either leave it where it is, or to move it to a sub-package in client?

And you'd prefer to move enumerable out here, only for it to be moved again pretty soonish?

[fredcarle]

You'd prefer an immutables package with a single type, than to either leave it where it is, or to move it to a sub-package in client?

Yes. I don't like that client is becoming a catch-all. And option.Option is weird and not idiomatic.

And you'd prefer to move enumerable out here, only for it to be moved again pretty soonish?

You mean it's going to be move to a separate repo? The work has been done so I don't think it's a big deal if we leave it there until it's taken out.

[AndrewSisley]

You mean it's going to be move to a separate repo?

Yes, it is to be shared by lens and defra (or less-likely, but possible, removed and replaced from both by a 3rd party lib)

The rest :)

Okay not a problem, so long as we are aware and still happy

[shahzadlone]

LGTM.

[codecov]

Codecov Report

Merging #939 (54e8b6b) into develop (82e0d2f) will decrease coverage by 0.24%.
The diff coverage is 90.10%.

@@             Coverage Diff             @@
##           develop     #939      +/-   ##
===========================================
- Coverage    60.19%   59.94%   -0.25%     
===========================================
  Files          165      157       -8     
  Lines        17884    17685     -199     
===========================================
- Hits         10766    10602     -164     
+ Misses        6155     6129      -26     
+ Partials       963      954       -9     

Impacted Files	Coverage Δ
client/request/commit.go	100.00% <ø> (ø)
client/request/mutation.go	100.00% <ø> (ø)
client/request/select.go	100.00% <ø> (ø)
db/fetcher/dag.go	58.62% <ø> (ø)
db/subscriptions.go	57.14% <ø> (ø)
events/events.go	100.00% <ø> (ø)
merkle/crdt/composite.go	80.00% <ø> (ø)
merkle/crdt/factory.go	85.71% <ø> (ø)
merkle/crdt/merklecrdt.go	47.05% <ø> (ø)
net/client.go	0.00% <0.00%> (ø)
... and 25 more