Removing the issue type context for a Service Desk field can break Request Types where it's in use

Issue Summary

If you add a field to a Service Desk request type and later remove that issue type from the field context, it will prevent those request types from loading in the customer portal.

It's not known which field types this does and doesn't apply to, but we are not able to reproduce the same issue with text fields but are with Select List (Single Choice) and Select List (Multiple Choice) fields.

Steps to Reproduce

1. Create a "Select List (Single Choice)" custom field 
2. Associate it with a Service Desk project and all issues types
3. Add this field to a request type in that Service Desk project
4. Test loading the customer request form and see that it loads properly and includes your new field
5. Go to the custom field page and click Configure
6. Click Edit Configuration
7. Remove the issue type for the above request type from the "Issue types" list (i.e., select any random other issue type)
8. Again try to load your customer request form. If you load the URL directly, it will now be a blank page. If you load the portal for that project and click the link, it will appear to soft refresh but nothing will load.
9. This may also affect Custom Fields without any associated projects in the context, regardless of the associated request type

Expected Results

The request page loads properly.

Actual Results

The page fails to load. If you attempt to load the URL directly, you will get a blank screen. If you click the link to the request from the portal, you will see a 500 error on /rest/servicedesk/1/customer/models.

The following error is found in atlassian-jira.log:

2020-11-19 15:21:40,720-0600 http-nio-48131-exec-7 ERROR uname 921x668x1 mlgopn 0:0:0:0:0:0:0:1 /servicedesk/customer/portal/1/create/1 [o.a.c.c.C.[.[localhost].[/j8131].[default]] Servlet.service() for servlet [default] threw exception
java.lang.NullPointerException
	at com.atlassian.jira.issue.customfields.impl.SelectCFType.getDefaultValue(SelectCFType.java:223)
	at com.atlassian.servicedesk.internal.fields.optionsprovider.SelectOptionsProvider.getDefaultValues(SelectOptionsProvider.java:67)
	at com.atlassian.servicedesk.internal.fields.optionsprovider.SelectOptionsProvider.apply(SelectOptionsProvider.java:40)
	at com.atlassian.servicedesk.internal.fields.ServiceDeskJIRAFieldServiceImpl$OptionsProvidersFunction.lambda$apply$1(ServiceDeskJIRAFieldServiceImpl.java:366)
	at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
	at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
...

Notes

• It also happens with other custom fields of multiple options. e.g. checkboxes, radio button;
• It does happen with all the custom fields types.
• The log entry for the error will variate if the custom field comes from an external plugin.
• The Safe Mode doesn't stop the problem when the custom field is from a plugin.

Workaround

There are two known workarounds at this time:

• Remove the field from the request type screen
• Change the context for the custom field to include the issue type of that request type

Refer to the KB article 500 error when trying to create a request from the Service Management Customer Portal for more detailed information about the workaround.

Suggestions

1. The system should give the user a warning or ask for confirmation before applying the modifications, in order to avoid accidental changes that could lead to this scenario.
2. The Jira Integrity Checker could find that and fix it, or at least point the need of fixing it to the Jira admins.