Use gogoproto's nullable=false

[jaekwon]

Avoiding pointers where it isn't necessary is generally better for security, as non-pointer/non-addressable values are immutable.

Also, some of our proto fields just shouldn't be nullable.

This PR addresses both issues.

[codecov-io]

Codecov Report

Merging #166 into develop will not change coverage.
The diff coverage is 47.61%.

@@           Coverage Diff            @@
##           develop     #166   +/-   ##
========================================
  Coverage    10.68%   10.68%           
========================================
  Files           12       12           
  Lines         2172     2172           
========================================
  Hits           232      232           
  Misses        1924     1924           
  Partials        16       16

Impacted Files	Coverage Δ
types/util.go	38.46% <ø> (ø)	⬆️
types/types.pb.go	5.02% <0%> (ø)	⬆️
example/dummy/helpers.go	100% <100%> (ø)	⬆️
example/dummy/dummy.go	66.66% <100%> (ø)	⬆️
example/dummy/persistent_dummy.go	63.1% <83.33%> (ø)	⬆️

---

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 e4b9f1a...a0e8a3a. Read the comment docs.

[melekes]

[ethanfrey]

Jae, while you are looking at protobuf format (and I agree with these changes), can you check out #165 ? I think it would be nice to express all Responses like (DeliverTxResponse, error), with a litlte adjustment to protobuf, we can add a simple golang function to extract the values from a Response into a more golang-esce format, and make us all hate protobuf just a little bit less.

[jaekwon]

@ethanfrey Yeah of course, I will look at it in the next 10 hours.

[jaekwon]

@ethanfrey Done, I responded there!

[odeke-em]

@jaekwon, here is a little counter. The problems with non-pointers are that:

• now we can't tell if something was set or not
• all data fields will be sent across the wire irrespective of if they are nil or not -- bandwidth wastage
• Lots of data copying when we invoke methods and functions
• the idea of being immutable might be a fallacy: for sure it provides security with args passed into when functions(however is this the common usage pattern?) vs normal usage(code in a common function where mutability will apply irrespective of if a pointer or not)

func fooWithPointer(b *Bar) {
   b.Time = time.Now()
}

// Security safe pattern, awesome
func fooWithoutPointer(b Bar) {
   b.Time = time.Now()
}

func zip(b Bar) {
   b.Time = time.Now()
   // do more stuff with b
   if b.Time.After(aLongTimeAgo) {
   }
   // Irrespective of if b was a pointer or not, we've mutated it
}

is zip the common usage pattern in our code?