Add new backend fields to be able to validate user input on required listing management fields

[emilyjablonski]

The issue here is form fields where we are toggling the answer on some other listing field will make it hard to validate required fields in listings management on the backend

Existing optional fields (according to #1542, we might need a more specific list)

• Can applications be picked up? (Y/N)
  • Currently toggled Y/N on existence of either applicationPickUpAddress or applicationPickUpAddressType
• Can applications be dropped off? (Y/N)
  • Currently Toggled Y/N on existence of either applicationDropOffAddress or applicationDropOffAddressType
• Are postmarks considered? (Y/N)
  • Toggled Y/N on existence of postmarkedApplicationsReceivedByDate, a field that shows after selecting yes
• Paper applications are mailed to another address (Checkbox)
  • Toggled checked on existence of applicationMailingAddress, a set of fields that show after selecting yes
• Do you want to show a waitlist size? (Y/N)
  • Toggled Y/N on existence of waitlistMaxSize
• Is there an application due date? (Y/N)
  • Toggle Y/N on existence of applicationDueDate

If any of the above fields end up being required, we would need a flag to indicate if the user said "no" to any of them otherwise the backend would not know how to validate.

Existing maybe-required fields (I currently don't have a list of what is required within the unit form)

• Within the individual unit form, How is rent determined? (Fixed amount / % of income)
  • Toggled to fixed on existence of monthlyIncomeMin and monthly Rent, toggled to percentage on existence of monthlyRentAsPercentIncome, otherwise null

New additions for application types

• Is there a digital application? (Y/N)
  • Toggled Y/N on existence of digital application method within applicationMethods
• Are you using the common digital application? (Y/N)
  • Toggled Y if the digital application method has the ApplicationMethodType of Internal, no if it has the ApplicationMethodType of ExternalLink
• Is there a paper application? (Y/N)
  • Toggled on the existence of a paper application method within applicationMethods
• Is this a referral opportunity? (Y/N)
  • Toggled on the existence of a referral application method

Since three of these new questions are required, we definitely at least need new fields for "digitalApplication", "paperApplication", and "referralOpportunity". Currently the backend can validate the required-ness fine if we say yes and fill in the application methods but not if we say no.

Since not all of these fields are required so we don't have the need to validate them on the backend, it seems like we don't need to add flags for all of them. None of the existing ones (apart from maybe the one on the unit form, which idk what’s required there) are required and it seems like those might be okay as-is, but we could also consider adding flags for those and it would simplify the frontend form.

[seanmalbert]

I think the main question, which you raised, is that if a user clicks "Yes" to any of them, regardless of the fields behind them being required, do we want to then say that they have to add that optional field?

If the answer is no, then we can just add the three fields you specified, but if the answer is yes, then we should add all of them. I think we should go with the easiest one first, which is to just add the three you call out. If we find during implementation that it would be easier to add all of them, then we can adjust then.