Fix configdb drop s3 not null

fix for

INFO:configdb-updater:==================== new message ====================
INFO:configdb-updater:processing data for thing 9246e41b-677d-4bc4-887d-8bae687420cc
ERROR:configdb-updater:storing thing failed.
Traceback (most recent call last):
  File "/usr/src/app/main.py", line 106, in on_message
    configdb.store_thing_config(conn, data)
  File "/usr/src/app/configdb.py", line 458, in store_thing_config
    parser = data["parsers"]["parsers"][idx]
             ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^
TypeError: list indices must be integers or slices, not NoneType

Bert Palm:14:50
oha das ist ein größeres übel... 

einen S3 store legen wir immer an
der S3-store braucht immer einen parser (sonst macht der S3 keinen sinn)
das frontend sendet aber nur bei (ext)SFTP einen Parser mit
:shit:

wir könnten entweder:

das configDB modell anpassen
keinen S3 erstellen (implikationen mir grad unbekannt)
immer Parser senden
ach u bei keinen S3 erstellen, müssen auch das DB modell auch anpassen.. 

[... joost bert talking...]
Bert Palm:
Ich meine es macht vlt auch sinn, keinen S3 zu erstellen wenn der nicht genutzt wird.. ich könnte eine einfache flyway migration machen das der s3 auch null sein darf.. das wär ja easy

Joost Hemmen:15:04
ja, evtl macht das Sinn. Für apis und MQTT möchte man den ja wirklich nicht nutzen

andererseits erzuegen wir auch für sftp things mqtt eingträge, die ohne mqtt_device_type sind. könnte man vergleichbar auch s3 einträge ohne parser erzeugen? wenn es dann aus welchem grund auch immer einen wechsel von mqtt zu sftp gibt, muss der parser am frontend ja nachgetragen werden

oder geht das nicht wegen der verlinkung der file_parser id?

Bert Palm:15:09
ja genau die verlinkung existiert

Joost Hemmen:15:09
möp

Bert Palm:15:10
iwie gefällt mir die iudee nicht einen storage zur verfügung zu stellen, der nix macht.. am ende nutzen den die USER noch für irgendwelchen quatsch

aber am ende ists egal, wo man das NOT NULL dropped

Joost Hemmen:15:13
Ich glaube da können wir nochmal ausführlich drüber diskutieren, wenn wir die dispatcher aktionen bündeln. da ist dann vielleicht wirklich sinnig, nach thing type zu unterscheiden und entsprechend buckets, mqtt user, ect anzulegen oder eben nicht

Bert Palm:15:13
jupp
hmm, aba watt machn wan jetz?

Joost Hemmen:15:16
s3 nullable machen würde ich sagen

Bert Palm:15:17
oki.. bin ich au dafür