BREAKING CHANGE: Allow for added.f and added6.f to be optional

[gdborton]

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update
[x] Bug fix
[ ] New feature
[ ] Other, please explain:

What changes did you make? (Give an overview)

Which issue (if any) does this pull request address?
#107

Is there anything you'd like reviewers to focus on?
Just compare against the spec I guess:
https://bittorrent.org/beps/bep_0011.html

[ThaUnknown]

actually....

Messages must contain at least one of the following fields: added, added6, dropped, dropped6.

does this matter for us during decoding? I feel like this will break shit downstream because they expect flags, but there are none

[SilentBot1]

actually....

Messages must contain at least one of the following fields: added, added6, dropped, dropped6.

does this matter for us during decoding? I feel like this will break shit downstream because they expect flags, but there are none

During decoding, no, currently we decode and do nothing with messages that don't have any of added, added6, dropped, dropped6, which is fine, as the BEP leaves it up to the client how they want to handle it.

It could cause issues downstream if flags are expected to not be undefined, but the BEP states flags are optional, so imo we should treat them as such.

We should probably release this as a breaking change if we're worried about this breaking stuff downstream. I'll update the title for now, but we can change it back if we change our minds / disagree about this being a breaking change.