Alter column metadata fields

[Anish9901]

Fixes #3714

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the develop branch of the repository
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added tests for the changes I made (if applicable).
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no
  visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[Anish9901]

@seancolsen Can you please add the appropriate docstrings for num_grouping and num_format?

[seancolsen]

Thanks @Anish9901. That was exactly what I asked for.

It turns out I've cycled through some different approaches to the options for num_grouping. And — embarrassingly — that vacillation is reflected in some commits I pushed here.

1. In master, the options for num_grouping are 'true' | 'false' (stringified booleans). Yes, weird. Long story.
2. I wanted to fix this in my current work, and I first though of 'force-yes' | 'force-no'. That's when I drafted this request for you (queued up with some other ones). It turns out the specific approach went stale. Sorry!
3. Then I changed my mind to a boolean and wrote some code comments to that effect.
4. Then I changed my mind again and settled on 'always' | 'auto' | 'never'. But I was moving too fast and didn't update the code comment. Ooops.

In trying to clean this up, I accidentally looked at my outdated code comment. And I ended up pushing 7116e7f to this PR to implement approach 3. Whoops! Now I've pushed for 4.. Oy vey! Been a long day.

Finally I pushed f96a9d2 to squash all these into one migration.

Can you look over this to make sure it's sane?

---

I'd rather not bother with documenting these parameters in metadata.py. They're not straightforward to explain. Documenting them in these docstrings is really quite tedious and has left me with the opinion that I'm not even sure the whole RPC documentation system is really worth it right now. I have documented the parameters quite thoroughly in the front end here. You can see how much I wrote there. It's crazy to me that we have over 100 lines of python code in metadata.py just to produce API docs for a very small portion of the API.

[Anish9901]

Your changes look good to me @seancolsen. Regarding migrations, you could've deleted the migrations file in this PR, made changes to the models and then run makemigrations again and then push the updated migrations file instead of squashing.

Regarding choices for fields, I discovered that these choices aren't enforced on the underlying db and serve as just documentation for now, if we do want these choices to be enforced we'd have to call full_clean() or clean_fields() before saving the model instance. These methods will raise a ValidationError if a field outside of the ones specified is passed to them.

[seancolsen]

I discovered that these choices aren't enforced on the underlying db

Funny. I also noticed that while testing this PR yesterday. I actually added it to the technical beta planning meeting: Validation of metadata values

I'm good with merging this PR now. I'll let you merge when you're ready.