modular protobuf issue (Dec. 6, 2019) recap

[Langdon White]

## How to determine if you have an issue and how to fix it:

run: ```sudo dnf list --installed *protobuf*```
if you get a result that looks like
```protobuf.x86_64  3.6.1-6.module_f31+6793+1c93c38```

you have encountered the problem. so please:

run: ```sudo dnf module disable eclipse```
run:  ```sudo dnf downgrade protobuf```

Any updates, as of a few hours ago, should be fine.

## What happened:
First and foremost, this issue appears to be caused by Modularity but, in
fact, is just an example of a policy not being followed. When a module
wishes to declare a "default stream"[1] it *must* not override a
traditional RPM without express permission from FESCo. The policy is
documented here[2].

Unfortunately, the recent change to enable an Eclipse Module Stream as a
default stream did not follow this policy and provided a different protobuf
RPM with different functionality.

## What we can do going forward:
* Increase the awareness of the policies for Fedora Modules
* Investigate an "early warning system" that would indicate to packagers
(modular and RPM) when they might be violating this policy
* Request dnf notify the user when they are enabling a superseding rpm from
a default stream module
* Request dnf provide an indication of what module is providing a
particular rpm (e.g. `dnf provides protobuf` not just indicate repo origin
but also module name and stream)

Langdon

[1]: if you are unfamiliar, this is the functionality that allows a module
stream to be used transparently by end users without them needing to
explicitly install a module.
[2]:
https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-d...