[wip] Make Context API non nullable

[smaldini]

• add hasKey : boolean
• add getOrEmpty : Optional

[codecov-io]

Codecov Report

Merging #780 into master will increase coverage by 0.35%.
The diff coverage is 95.91%.

@@             Coverage Diff              @@
##             master     #780      +/-   ##
============================================
+ Coverage      82.5%   82.85%   +0.35%     
- Complexity     3026     3145     +119     
============================================
  Files           312      314       +2     
  Lines         25439    25710     +271     
  Branches       4752     4831      +79     
============================================
+ Hits          20989    21303     +314     
+ Misses         2953     2928      -25     
+ Partials       1497     1479      -18

Impacted Files	Coverage Δ	Complexity Δ
.../reactor/core/publisher/MonoSubscriberContext.java	70% <ø> (ø)	2 <0> (?)
...src/main/java/reactor/core/publisher/FluxSink.java	100% <ø> (ø)	0 <0> (ø)	⬇️
...e/src/main/java/reactor/util/context/Context5.java	100% <100%> (ø)	21 <21> (?)
...e/src/main/java/reactor/util/context/ContextN.java	100% <100%> (+66.66%)	14 <9> (+11)	⬆️
...e/src/main/java/reactor/util/context/Context3.java	100% <100%> (ø)	15 <15> (?)
...e/src/main/java/reactor/util/context/Context0.java	100% <100%> (+55.55%)	7 <2> (+4)	⬆️
...e/src/main/java/reactor/util/context/Context4.java	100% <100%> (ø)	18 <18> (?)
...src/main/java/reactor/core/publisher/FluxPeek.java	92.68% <100%> (+0.44%)	12 <0> (ø)	⬇️
...ore/src/main/java/reactor/core/publisher/Mono.java	95.04% <100%> (-0.02%)	226 <1> (-1)
...ore/src/main/java/reactor/core/publisher/Flux.java	100% <100%> (ø)	465 <1> (-1)	⬇️
... and 31 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1d666fe...bac409c. Read the comment docs.

[simonbasle]

2 concerns with that approach:

• is throwing on a get with bad key a good idea at all? think about the usage patterns and the try/catch or if(hasKey) this implies? granted there is a getOrEmpty but... I think I'd leave get as Nullable.
• why remove getOrDefault at all? It is useful IMO, as much as getOrEmpty...

If you decide to keep the exceptions, at least document them in the javadocs ⚠️

[smaldini]

It's wip but the point here is a get(...) that would return null would do so indefinitely. Context is immutable, a null key will never turn non null for a given ctx. User can still query presence of a key with hasKey or getOrEmpty (which superseed getOrDefault via Optionsl.orElse),

[simonbasle]

got it, wasn't sure what would be the most complicated to use between a nullable get or a throwing get... but in any case it should be marked as less than ideal, maybe even directly deprecated?

fair point on getOrEmpty().orElse(), just thinking it just might be a bit more readable as a getOrDefault() alias / syntactic sugar?

getOrDefault re-added

[simonbasle]

@smaldini was thinking about:

• adding Context1-Context5 implementations (hidden, instead of the map one)
• means of creating a Context1 directly
• maybe the same for sizes up to 5, but what of the key-value parameters (have a look at how java is planning on doing that for sequence literals?)
• add putAll

[simonbasle]

note on putAll: since this would return a Context, it clashes with Map#putAll in the ContextN implementation. I'm going with putAllOf but if you have a better suggestion @smaldini ...

[simonbasle]

@smaldini following @rwinch comment on getOrDefault I reinstated the nullabity of the default. Kept it as a separate commit for easy drop / revert, and rebased the rest, grouping your changes, my changes and an unrelated one (so this whole PR is ready for a rebase-and-merge).